Re: A puzzle: reset --hard and hard links

[Junio C Hamano <gitster@pobox.com>]

"brian m. carlson" <sandals@crustytoothpaste.net> 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).