is there a "symlink" option for cloning a repo in a separate filesystem?

  reading "man git-clone", and i understand the mechanics of the local
protocol, so that if i run:

  $ git clone /path/to/repo

then "files under .git/objects/ directory are hardlinked to save space when possible."

  but if the repo is in a separate filesystem, or on an NFS mount,
hardlinks clearly won't work, so what happens then? does it default
all the way back to regular copies? is there no intermediate symlink
feature that would still work? (i suspect i am far from the first
person to wonder this.)

rday

On 2017-09-23 10:22, Robert P. J. Day wrote:

Isn't that what "--reference" is good for ?

https://git-scm.com/docs/git-clone

or

man git-clone

PS: Robert P. J. Day <rpjday@crashcourse.ca> Does not work from web.de

On Sat, Sep 23, 2017 at 04:22:32AM -0400, Robert P. J. Day wrote:

I believe the current behavior is to make a copy. However, if the source repo is reasonably well packed, you won't be copying that many files anyway. You can always run git gc in the source repo to speed up that process if you're going to be making many clones.

As Torsten pointed out, --reference is available. If your source repository is ephemeral (or otherwise won't last as long the destination repository), then you won't want to use that option, as you'll lose data. The --shared option documents all the sharp edges.

"Robert P. J. Day" <rpjday@crashcourse.ca> writes:

After a normal "clone", you want the new repository as independently usable even after the original repacks, rewinds some of its branches, or even goes away completely.

Imagine that we used symbolic links to point at loose object files in the original and then the original repacked all of them into a new packfile. The symbolic links in the new repository will keep pointing at their now-missing counterparts, and your new repository is corrupt, because it does not know about the new packfile that is meant to replace them in the original repository.

The sensible choices available to us are only the two: hardlink or copy. Using symbolic links does not make any sense in the context of "clone". Hardlinks make sense only because object files are only created or removed but never modified in-place, and removal in the original repository does not affect the "copy" you have in the new repository.

As others mentioned, use "--reference", perhaps like

	git clone --reference /path/to/repo --no-local /path/to/repo

is one way to avoid having to make copies. It first declares that your new repository will keep depending on the project it borrowed from forever with "--reference"; with that declaration, your new repository does not have to store copies of objects that the repository pointed at with --reference has, so the clone operation itself, which wants to copy the objects in the source repository, does not have to copy any.