Re: How to stop sharing objects between repositories

[Junio C Hamano <gitster@pobox.com>]

Jeff King <peff@peff.net> writes:

> Subject: [PATCH] docs: mention how to break alternates dependency
>
> A user who has created a repository dependency by using "git
> clone -s" does not necessarily know where to look to find
> out how to break that dependency. Let's mention it right
> under "-s", where they are most likely to find it.
>
> Signed-off-by: Jeff King <peff@peff.net>
> ---
>  Documentation/git-clone.txt |    5 +++++
>  1 files changed, 5 insertions(+), 0 deletions(-)
>
> diff --git a/Documentation/git-clone.txt b/Documentation/git-clone.txt
> index b14de6c..87fa687 100644
> --- a/Documentation/git-clone.txt
> +++ b/Documentation/git-clone.txt
> @@ -72,6 +72,11 @@ These objects may be removed by normal git operations (such as 'git-commit')
>  which automatically call `git gc --auto`. (See linkgit:git-gc[1].)
>  If these objects are removed and were referenced by the cloned repository,
>  then the cloned repository will become corrupt.
> ++
> +To break the dependency of the cloned repository to the source
> +repository, run `git repack -a` in the cloned repository, which will
> +create a new pack in that repository with all referenced objects,
> +including those in the source repository.

After reading this, two points come to my mind.  They may or may not be
issues.

 (1) Such a user does not necessarily know a casual "git repack -a" breaks
     the dependency, defeating the -s option s/he deliberately used in
     order to save disk space in the first place.  Perhaps we can reword
     this further to kill two penguins with a single stone?

	Note that the pack resulting from running `git repack -a` in the
	repository cloned with the `-s` option will include objects that
	are borrowed from the source repository.  It essentially breaks
	the dependency created by cloning with the `-s` option by copying
	the objects from the source repository.  To keep borrowing from
	the source repository to save disk space, do not use `repack -a`.

     We should suggest an alternative immediately after this sentence,
     e.g. "Instead, use `repack -l`" or something, but somebody should
     check if it is a valid/viable alternative.

 (2) IIRC, "git gc --auto" runs "repack -A".  What is its effect with
     respect to this dependency between object stores?  I suspect it would
     also break the dependency, but if so, is it a good thing?  Perhaps
     should we change it to use a version that keeps the dependency
     instead?