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:
signature.asc
Description: PGP signature
