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

From: Ævar Arnfjörð Bjarmason <avarab@gmail.com>
Date: Jan 25, 2022, 11:33 UTC
Message-ID: <220125.865yq8ghae.gmgdl@evledraar.gmail.com>
In-Reply-To: <CABrKpmDjrTPhL_55YaXEAVTEmu8iZEsKUJYab7OgK0=w9d_7MA@mail.gmail.com>

On Mon, Jan 24 2022, Michael Herrmann wrote:

Show 23 quoted lines

> 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).