Thank you for your explanations Junio. This is the first part where I differ: > $ ln -f a b My hard link is outside the repo. In your example, it makes sense that Git has to sever the hard link to be able to give the files different contents. In my case and example, this complication is not present. And it does not address the main point: My working tree is clean. `git reset --hard HEAD` (not HEAD^ like you had) should not do anything. Finally, your (kind!) explanation does not give a reason why calling `git status` should change the behavior that Git unnecessarily severs the hard link. My suspicion is that Git keeps a cache of the stat(...) result of files. An additional hard link increases the .st_nlink count of this struct. `git reset` compares the cached stat(...) values to the actual ones and sees that one has changed. `git status` does the same but is smart enough to realize that the additional hard link does not change anything. It writes this to the cache. `git reset` should also be smart!
