Johannes Sixt <johannes.sixt@xxxxxxxxxx> 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. - To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html