Re: Managing multiple branches in git

Andres Freund escribió:

> git clone --reference common_repo
> + small
> + staying small
> + fast
> + windows supported
> +- push/fetch needed
> - possibly unsecure if you delete from the master repository - which one
> can easily prevent
>
> git clone --shared
> Essentially the same as the last above

I think these are the two usable options. They will probably end up
making sense (to me at least). We only need to make sure we don't
accidentaly corrupt the WCs, but we should be safe because we don't
intend to "delete branches" in the upstream repository. The note in the
docs:

--shared, -s
When the repository to clone is on the local machine, instead of
using hard links, automatically setup .git/objects/info/alternates
to share the objects with the source repository. The resulting
repository starts out without any object of its own.

NOTE: this is a possibly dangerous operation; do not use it unless
you understand what it does. If you clone your repository using
this option and then delete branches (or use any other git command
that makes any existing commit unreferenced) in the source
repository, some objects may become unreferenced (or dangling).
These objects may be removed by normal git operations (such as
git-commit) which automatically call git gc --auto. (See git-
gc(1).) If these objects are removed and were referenced by the
cloned repository, then the cloned repository will become corrupt.

--reference <repository>
If the reference repository is on the local machine automatically
setup .git/objects/info/alternates to obtain objects from the
reference repository. Using an already existing repository as an
alternate will require fewer objects to be copied from the
repository being cloned, reducing network and local storage costs.

NOTE: see NOTE to --shared option.

--
Alvaro Herrera http://www.CommandPrompt.com/
PostgreSQL Replication, Consulting, Custom Development, 24x7 support