"brian m. carlson" <sandals@xxxxxxxxxxxxxxxxxxxx> writes: > Whether it happens in this particular case probably depends on what data > is in the index and whether it's considered stale, since if the file is > out of date, I believe a git reset --hard will replace it rather than > try to determine whether it's up to date. True, but I think it answers a different question, which was "to replace or to overwrite". I do not recall any codepath in git proper (I do not know about third-party tools and scripts around the fringe, though) that overwrites working tree files instead of writing into new files and replacing them. If there is a hardlink to outside the working tree of a tracked path, and "git reset --hard [<committish>]" needs to modify the contents of that tracked path because it does not match what is recorded in the committish, I think it is the right thing to severe the link and leave the path outside the working tree intact. If we instead overwrote, we will damage "the other file" that shares the hardlink, which is outside the working tree hence outside our control. Also, if two paths inside a working tree are made into hardlinks to each other, whenever Git needs to update either of them, we would severe the link, i.e. not ovewrite but replace, and it is the right thing to do, since Git trakcs these two paths as two separate things (i.e. the index has one entry for each of these paths).
