Re: How to stop sharing objects between repositories

[Mike Galbraith <efault@gmx.de>]

On Sun, 2009-08-16 at 12:16 -0700, Junio C Hamano wrote:
> 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?

Perhaps a runtime warning that you're about to break it?  This user may
not even be the one who set the thing up, no?

	-T. Peanut Gallery