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

["Ævar Arnfjörð Bjarmason" <avarab@gmail.com>]

On Mon, Jan 24 2022, Michael Herrmann wrote:

> 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!

What you're observing is that we tweak the index when various commands
are run, some of that is documented, and others we consider purely
implementation details. Whether we sever a hard link relationship is
definitely on the "implementation detail" side of that.

I.e. that you can observe a behavior difference here doesn't mean that
it's a bug, it means that you're poking at behavior that was never
supposed to work this way, or be stable.

That being said I don't see a reason for why we shouldn't ever support
what you're requesting here in some way. E.g. when we spin up different
a different 'git worktree' on the same storage we could optionally
hardlink to an existing checkout to save space.

This would be useful e.g. for spinning up a bunch of trees to run
compilations on, where much of the checkout tree will be duplicated.

And this probably won't match your use-case, but I wonder how far you
could get with the post-checkout hook, i.e. to have it run around after
a checkout and fix up things that aren't hard links to be hardlinked
appropriately.

I don't know of a tool to take two directories and hardlink things where
possible, but it wouldn't be hard to write. I thought rsync could, but
it appears just to support copying things as hardlink, not "fixing"
files with the same content to be hardlinks after the fact (but maybe
I've just missed a way to operate it).