17

I started using hard links instead of symbolic links to organize files ...

I've been doing this for pictures I take to categorize them as well as indicate which ones I want to print, etc.

I'm using git to backup my images and it appears that git thought they were new files as the repository grew about 1GB in size. Git does really well in detecting renames if I don't use git to rename the file, but does it also handle hard links?

Walter

5
  • 3
    All normal files are hard links. Perhaps you meant "files with multiple hard links"? Apr 24, 2011 at 21:23
  • Yes, that is what I meant.
    – Walter
    Apr 25, 2011 at 0:24
  • 1
    Correct me if I'm wrong, but doesn't git more track content? Why would it matter if the files have the same content, then - after all, they are technically the same file.
    – new123456
    Apr 25, 2011 at 0:57
  • 1
    For people who stumble across this - perhaps consider using Symbolic links instead? stackoverflow.com/q/954560/492
    – CAD bloke
    Feb 23, 2013 at 8:12
  • It sounds like you want a tag-based file system.
    – Nayuki
    Aug 2, 2017 at 3:15

1 Answer 1

14

Multiply linked tracked files will not cause Git’s object store to grow much since each link will be represented by the exact same blob object. Your working tree, however, might end up growing due to broken links.

Git does not track whether tracked, working tree files are hard links to the same file.

Git will leave multiply linked, tracked, working tree files alone if you do not ask it to do anything that would involve modifying the content at those pathnames or deleting the pathnames’ directory entries. But, if you were to (e.g.) checkout an old commit or branch and then switch back to your normal, most recent branch/commit, then Git will end up “breaking” the hard links (replacing the affected pathnames with new (but identical) files instead of recreating your multiply linked situation).

To recover your multiply linked status you could write a program to scan for identical files and relink them to any one of the files. Such a “relink” operation may be more complicated if all the links are not in the working tree itself or, at least, not in some easily identifiable “external” location (i.e. it will probably be difficult to recover the links if you are linking “random” files from all over your home directory into a “backup” repository and using Git to modify the working tree).

The idea has come up on the Git mailing list:

2

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .