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

["brian m. carlson" <sandals@crustytoothpaste.net>]

[-- Attachment #1: Type: text/plain, Size: 1653 bytes --]

On 2022-01-19 at 20:37:48, Michael Herrmann wrote:
> Hi all,
> 
> It seems `git reset --hard` recreates files that have external hard
> links. Is this intended?
> 
> The example below highlights the behavior. I have an unchanged Git
> repository. When I create an (outside) hard link to a file in the
> repository, then `git reset --hard` re-creates the file with a new
> modification time and inode. This occurs on Debian 11 with Git 2.30.2
> but not on Debian 10 with Git 2.20.1
> 
> > git init
> Initialized empty Git repository in .../git-test/.git/
> > echo "test" > file.txt
> > git add file.txt
> > git commit -m "Import"
> [main (root-commit) f73709f] Import
>  1 file changed, 1 insertion(+)
>  create mode 100644 file.txt
> > stat -c '%y' file.txt
> 2022-01-19 18:43:52.147781748 +0100
> > ls -i file.txt
> 74458979 file.txt
> > ln file.txt ../file.txt
> > git reset --hard
> HEAD is now at f73709f Import
> > stat -c '%y' file.txt
> 2022-01-19 18:44:47.013167127 +0100
> > ls -i file.txt
> 74458995 file.txt
> 
> Can this behavior be avoided?

Git generally doesn't guarantee that it will preserve hard links in any
particular situation.  It can and does replace files rather than writing
over the existing ones, so this behavior is expected in at least some
circumstances.

Whether it happens in this particular case probably depends on what data
is in the index and whether it's considered stale, since if the file is
out of date, I believe a git reset --hard will replace it rather than
try to determine whether it's up to date.
-- 
brian m. carlson (he/him or they/them)
Toronto, Ontario, CA

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 262 bytes --]