* Re: is there a "symlink" option for cloning a repo in a separate filesystem?
2017-09-23 8:22 is there a "symlink" option for cloning a repo in a separate filesystem? Robert P. J. Day
@ 2017-09-23 11:32 ` Torsten Bögershausen
2017-09-23 18:55 ` brian m. carlson
2017-09-24 0:12 ` Junio C Hamano
2 siblings, 0 replies; 4+ messages in thread
From: Torsten Bögershausen @ 2017-09-23 11:32 UTC (permalink / raw)
To: Git Mailing list
On 2017-09-23 10:22, Robert P. J. Day wrote:
>
> 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
>
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
^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: is there a "symlink" option for cloning a repo in a separate filesystem?
2017-09-23 8:22 is there a "symlink" option for cloning a repo in a separate filesystem? Robert P. J. Day
2017-09-23 11:32 ` Torsten Bögershausen
@ 2017-09-23 18:55 ` brian m. carlson
2017-09-24 0:12 ` Junio C Hamano
2 siblings, 0 replies; 4+ messages in thread
From: brian m. carlson @ 2017-09-23 18:55 UTC (permalink / raw)
To: Robert P. J. Day; +Cc: Git Mailing list
[-- Attachment #1: Type: text/plain, Size: 1319 bytes --]
On Sat, Sep 23, 2017 at 04:22:32AM -0400, Robert P. J. Day wrote:
>
> 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.)
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.
--
brian m. carlson / brian with sandals: Houston, Texas, US
https://www.crustytoothpaste.net/~bmc | My opinion only
OpenPGP: https://keybase.io/bk2204
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 867 bytes --]
^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: is there a "symlink" option for cloning a repo in a separate filesystem?
2017-09-23 8:22 is there a "symlink" option for cloning a repo in a separate filesystem? Robert P. J. Day
2017-09-23 11:32 ` Torsten Bögershausen
2017-09-23 18:55 ` brian m. carlson
@ 2017-09-24 0:12 ` Junio C Hamano
2 siblings, 0 replies; 4+ messages in thread
From: Junio C Hamano @ 2017-09-24 0:12 UTC (permalink / raw)
To: Robert P. J. Day; +Cc: Git Mailing list
"Robert P. J. Day" <rpjday@crashcourse.ca> writes:
> 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.)
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.
^ permalink raw reply [flat|nested] 4+ messages in thread