"David Frech" <nimblemachines@xxxxxxxxx> writes:
> Could you, for my sake and the list's (if others are as confused) be
> clearer about the distinctions among -l, -s, and --reference? Exactly
> what they do, and their orthogonality (or lack of) really isn't clear
> from reading the man page.
Clone "-l" makes the new repository share the initial set of
objects from the original by hardlinking each and every file
under .git/objects/. After "-l" clone, two repositories are
truly independent, except for the fact that the new one
obviously treats the old one as its "origin".
There are a few implications:
- New objects created in the new repository is not visible in
the original repository and vice versa. If you do
development in the new repository, and push the results back
to the original, the push will involve object transfer. If
your original one is updated (perhaps with git-pull from the
upstream), you would need to update the clone separately.
- You can safely rewind the refs in the original repository and
run git-prune there without worrying about corrupting the
cloned repository.
Clone "-s" does not make hardlinked copy like "-l" makes. It
creates an entry in .git/objects/info/alternates file in the new
repository, that instructs git that any object missing in the
new repository should be looked up in the cloned repository.
New objects created in the original will be shared with the
cloned repository because of this, but the sharing does not
happen in the other direction. Also if you run "rebase" (or
"reset --hard" to rewind the tip of branches) in the original
repository and then run git-gc, it would cause some objects to
become unneeded in the original repository and they can get
discarded. If your cloned repository depends in them, you will
be in trouble. So you would need to be a bit careful when you
use "-s" --- the rule of thumb is not to rewind the branches, or
if you do, make sure the cloned ones are kept in sync
(i.e. rewind the commits lost in the original the same way in
the clone).
The "--reference" option uses the same mechanism as "-s" uses to
share objects from a local repository. It is useful if you have
a repository of a different project that is related to the
project you are cloning from outside. For example, if you have
a copy of LInus's Linux 2.6 kernel repository locally, and if
you want to clone 2.6.x.y maintenance "stable" repository, you
know the two repositories are alike and share a lot of objects,
so you would:
$ git clone --reference ../linus-2.6/ git://.../linux-2.6.x.y/ stable.git
To this option, because it uses the same "alternate object
store" mechanism as "-s" option does, the same "be careful
rewinding the branches in the original" caveat applies. Because
Linus never rewind his branches, the above clone is safe.
For the purpose of "keep rebuilding 'next' from git.git
repository", because my 'next' will never rewind by social
convention, you do not have to worry about the "original
repository being rewound and losing objects" problem, either, as
long as 'next' is the branch you rebuild in the "nightly"
repository.
-
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
