Dmitry Potapov wrote: > On Mon, Apr 21, 2008 at 07:23:10PM -0500, Brandon Casey wrote: >> Dmitry Potapov wrote: >> >>> Johannes' patch removed this option, which IMHO was a significant user >>> interface improvement. >> Unless I missed something, this option has not been removed. The original >> purpose for its existence (which was to cause git-gc to call git-prune) >> has been removed. The call to git-prune within git-gc will remove _loose_ >> unreferenced objects, but _packed_ unreferenced objects are removed by >> repack. The --prune option to git-gc is still used to adjust the call to >> git-repack so that packed unreferenced objects are discarded. > > I thought that it had no effect any more, because it had been removed > from the git-gc man page. Now I have looked at the code now, and it seems > the difference between running git gc with and without the prune option > is that with this option the git repack is called with '-a' option while > without it with '-A'. Unfortunately, the '-A' option in the git-repack > is also undocumented, but based on the reading git-repack.sh, you are > right. So, now I wonder wether removing the --prune option from the man > page was the right thing to do. > >>> diff --git a/Documentation/git-clone.txt b/Documentation/git-clone.txt >>> index 9758243..c1bf814 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 a branch or use >>> +any other git command that makes any previous existing commit >>> +unreachable, then after some time linkgit:git-gc[1] may remove >>> +unreachable objects, and this will break the cloned repository. >>> +Because some git commands may run git-gc, it may happen at any >>> +time after gc.pruneExpire time since commits became unreachable. >> I agree that something should be said here about shared repositories, >> but I think this wording is a little complicated (disclosure: I also >> submitted some text for this a few weeks ago :). Of course something >> is better than nothing. >> >> Here's the blurb I submitted if you're interested: >> +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. > > I like your wording better though I still prefer to mention that > deleting branches is just one of many possible commands that may > create unreferenced commits, i.e. something like that: > > ... repository using this option and then delete branches (or use any > other git command that makes any existing commit unreferenced) ... That's fine, but one of us needs to resubmit. Care to do the honors? :) -brandon -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
