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

[<rsbecker@nexbridge.com>]

On January 24, 2022 4:19 PM, Junio wrote:
> Michael Herrmann <michael@herrmann.io> 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.

I think there are more use cases here than are apparent but also some
serious question about why one would do this.

In a Linux/POSIX environment, one can do a hard link to a file inside a git
repo, change the file using something like vim, and have git recognize that
there is a change in git status. However, this only works on some platforms.
Hard links do not have a 100% consistent semantic from one OS to another,
one file system to another, or even between editors and scripts. As Junio
pointed out, using a > operator on a hard link is likely going to replace
the file instead of modifying the existing one. >> might correctly append
and have git recognize it in a git status... on some platforms.

Making git consistent in this situation across every possible situation is
not only impractical, it is likely impossible and cutting down what git is
allowed to do so that only those common things are implemented might gut git
badly.

If you are looking for doing external edits while keeping git notified, I
would suggest wrapping the file modification in a script that is aware of
hard links so that you get the results you want.

Alternatively, a soft link made externally to a physical git file location
might do what you want - assuming your platform supports soft links. Your
modification script/program/etc. would use the file directly in git instead
of the hard link inode, so git is happy. A git status would see the change
because the file really only exists in git. Other git operations, like
restore, switch, etc., would cause the physical file to be modified
correctly, and anything using the referencing soft link would see the
change. Note: I am not suggest soft-linking from inside git to outside.

--Randall