Re: [PATCH] git-clone.txt: Adjust note to --shared for new pruning behavior of git-gc

> Johannes Schindelin wrote:
> 
> > On Thu, 3 Apr 2008, Brandon Casey wrote:
> > 
> >> diff --git a/Documentation/git-clone.txt b/Documentation/git-clone.txt
> >> index 9758243..d3ab00b 100644
> >> --- a/Documentation/git-clone.txt
> >> +++ b/Documentation/git-clone.txt
> >> @@ -65,10 +65,12 @@ OPTIONS
> >>  +
> >>  *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, then delete branches in the
> >> -source repository and then run linkgit:git-gc[1] using the
> >> -'--prune' option in the source repository, it may remove
> >> -objects which are referenced by the cloned repository.
> >> +repository using this option and then delete branches in the
> >> +source repository, some objects may become unreferenced (or dangling).
> >> +These objects may be removed by normal git operations (such as git-commit[1])
> >> +which automatically call git-gc[1]. If these objects are removed and
> >> +were referenced by the cloned repository, then the cloned repository
> >> +will become corrupt.
> > 
> > Please note that if you delete a branch _after_ running git-gc, the next 
> > git-gc would remove those objects anyway, since the first git-gc packed 
> > the objects, and they were therefore no longer dangling.
> 
> I thought they would be retained unless --prune was used. git-gc uses the
> -A option to repack when --prune is not used and -a when --prune is used.

> But what I was really trying to point out in the documentation changes 
> was that now _other_ commands such as git-commit are also unsafe since 
> they call 'git-gc --auto' and could cause loose unreferenced objects to 
> be deleted. So it is not enough to just avoid calling git-gc when 
> dealing with a --shared repository.