Home/ Questions/Q 515025
In Process

The Archive Base Latest Questions

Editorial Team
  • 0
Asked: 2026-05-13T07:35:08+00:00

I observed the following behavior while working with the perl code base (on branch

  • 0

I observed the following behavior while working with the perl code base (on branch maint-5.004):

bash-3.2$ git status | grep modified
#       modified:   configure
bash-3.2$ git reset --hard
HEAD is now at 9a4fb7e copy over bleads .gitignore
bash-3.2$ git status | grep modified
#       modified:   Configure
bash-3.2$ git reset --hard
HEAD is now at 9a4fb7e copy over bleads .gitignore
bash-3.2$ git status | grep modified
#       modified:   configure

This is happening because the two files share an inode (they are the same file), but they are different in the git index. My question is: how did that happen? If git is tracking 2 links to the same file, should git be expected to flag it as an error when only one of them is modified? Is this a git bug or user error?

Update:

It appears that the issue is not with git, but is related to case sensitivity of the filesystem (hfs+).

$ mkdir tmp
$ cd tmp
$ touch foo
$ ls -i foo Foo
10301082 Foo    10301082 foo

I think perhaps that OS X needs to reconsidered as a useful platform for development, as this behavior is absurd.

Share

Leave an answer

You must login to add an answer.

Need An Account,

1 Answer

  1. Editorial Team

    Source control systems generally have problem tracking hardlinks. You should have made one of them a symlink and add the symlink to git and it would work fine. Git can handle symlinks fine.

    Unless you would somehow point to a source control system that a file you add to repository is a hardlink, it has no way to know and it certainly won’t go comparing inodes of all files on every add just to find out if that is the case.

    Even systems that do allow hardlinks try to avoid creating them at all costs, since the number of problems created by hardlinks is quite high and all the resulting bugs and inconsistencies are very hard to track. After a while and few renames and moves of one of the links, two different teams could each own one piece of the hardlink in their part of source tree and a fight over the content of the version tree of the object ensues with nobody being too wise about why with no modifications done to your part of source tree a file content is changing. It’s better to use symbolic links.

    • 0