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,
automaticallysetup .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
youclone your repository using this option and then delete branches (or use any other git command
thatmakes 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
automaticallycall 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
repositoryas an alternate will require fewer objects to be copied from the repository being cloned,
reducingnetwork and local storage costs.
NOTE: see NOTE to --shared option.
--
Alvaro Herrera http://www.CommandPrompt.com/
PostgreSQL Replication, Consulting, Custom Development, 24x7 support
