Michael Herrmann <michael@xxxxxxxxxxx> writes:
>> 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.
