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

From: Junio C Hamano <gitster@pobox.com>
Date: Jan 24, 2022, 21:19 UTC
Message-ID: <xmqqfspc3k8k.fsf@gitster.g>
In-Reply-To: <CABrKpmB7UEGzLCiNHQtY5-Dt16jLkpcpBEx3o8y9OBGZ418keA@mail.gmail.com>

Michael Herrmann <michael@herrmann.io> writes:

Show 11 quoted lines

>> It is merely because you helped Git to realize
>
> I don't want to "help Git realize". I'm sorry but in my opinion `git
> status` should not have any effects on other commands. I don't
> understand how you can argue that calling `git status` is a valid fix
> to "help Git".
>
>> With another step 1.5 "append a line to the file in question", git
>> should severe the link,
>
> I don't want to sever the hard link. I want to avoid that it gets severed.

Sorry, if that is the case, what you want is not a version control, and it is certainly not Git. You want something else.

Think about this scenario.

    $ rm -fr one && git init one && cd one
    $ echo 0 >a; echo 0 >b; git add a b; git commit -m zero

We have two files, a and b, each of which has "0" in it.

    $ echo 1 >b; git add b; git commit -m one

Now they have "0" and "1" respectively.

    $ echo 2 >a; echo 2 >b; git commit -a -m two
    $ ln -f a b
    $ git diff
    $ git diff HEAD

Now they have "2". Since they have identical contents, "diff" would report no difference relative to the index or HEAD, even after we manually break the working tree by making one of them a hardlink to the other.

Now, what should this command do?

    $ git reset --hard HEAD^

What the user is asking is (1) to move the branch to point at the previous commit, which had 0 and 1 in a and b respectively, and (2) to make sure that the index and the working tree contents match what is recorded in the commit.

So for Git to be a usefully correct version control system, it is essential to make sure what it writes out would not affect any path other than the one it is writing out. When it writes "0" to "a", it MUST break the hardlink from elsewhere that points at "a" before it does so. Otherwise, the "0" it writes into "a" will also be seen elsewhere, which is not what the updated HEAD (i.e. commit "one") wants to see. The same for "b" when it is updated from "2" to "1" when this happens.