Question

Git assumes -l when a clone is requested from a local file system, presumably to speed up the clone and save disk space. What are the implications of this type of clone? If I clone a repository twice and then make a commit to one, then will the changes be visible in the other clone? I’m wondering if Git is careful to copy on writes. If the original repository is read only, then will that present problems for the clones?

Answer 1

The git clone manpage states about -l:

When the repository to clone from is on a local machine, this flag bypasses the normal “git aware” transport mechanism and clones the repository by making a copy of HEAD and everything under objects and refs directories. The files under .git/objects/ directory are hardlinked to save space when possible.

This means that you will get a hardlink for all Git objects which has no real implications because those objects are immutable anyway and Git does not update them once they are created. You also get actual copies of HEAD and other symbolic references, so changes to them in one repository will not be seen in others. If you commit a change, a few new objects will be created under .git/objects and the HEAD reference will be updated to point to the latest commit (which will be one of the newly created objects); no existing objects will be updated, so you don’t have to worry about the hardlinks.

The manpage states one implication, which may be of interest:

To force copying instead of hardlinking (which may be desirable if you are trying to make a back-up of your repository), but still avoid the usual “git aware” transport mechanism, –no-hardlinks can be used.

The downside of hardlinks is that they refer to the same actual inodes on disk, so if one Git object gets corrupted, all your local clones that hardlink to it will have a corrupted object. Without hardlinks, you will have actual backup copies of all of your objects.