From: Mike Galbraith Date: Mon, 17 Aug 2009 02:21:22 GMT Subject: Re: How to stop sharing objects between repositories Message-ID: <1250475682.7155.16.camel@marge.simson.net> In-Reply-To: <7vmy5z603d.fsf@alter.siamese.dyndns.org> On Sun, 2009-08-16 at 12:16 -0700, Junio C Hamano wrote: > Jeff King 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 > > --- > > 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