Re: Is cp -al safe with git?

Johannes Sixt [off-list ref] writes:

For one reason or another I would like to "clone" a local repo including the
checked-out working tree with cp -al instead of cg-clone/git-clone, i.e.
have all files hard-linked instead of copied.

Can the copies be worked on independently without interference (with the git
tool set)?

One thing I noticed is that git-reset or probably git-checkout-index breaks
links of files that need not be changed by the reset. Example:

# make 2 files, commit
$ mkdir orig && cd orig
$ git-init-db 
defaulting to local storage area
$ echo foo > a && cp a b && git-add a b && git-commit -a -m 1
Committing initial tree 99b876dbe094cb7d3850f1abe12b4c5426bb63ea

# 2nd commit modifies only one file:
$ echo bar > a && git-commit -a -m 2

# create the copy:
$ cd ..
$ cp -al orig copy
$ cd copy

# working files are hard-linked:
$ ls -l
total 8
-rw-r--r-- 2 jsixt users 4 Nov 16 19:24 a
-rw-r--r-- 2 jsixt users 4 Nov 16 19:23 b

# nuke a commit:
$ git-reset --hard HEAD^
$ ls -l
total 8
-rw-r--r-- 1 jsixt users 4 Nov 16 19:24 a
-rw-r--r-- 1 jsixt users 4 Nov 16 19:24 b

I'd have expected that the hard-link of b remained and only a's link were
broken. Does it mean that git-reset writes every single file also for large
trees like the kernel? I cannot believe this. Can someone scratch the
tomatoes off my eyes please?

Most likely you didn't run "update-index --refresh" after "cp -l"?
Not just in the new copied repository but in the original
repository I would suspect you would see this.  This is because
the index caches ctime and making a new hardlink manipulates the
files' inodes, thus making the cached information stale.