Hi, On Thu, 3 Apr 2008, Brandon Casey wrote: > 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. Oh, you're right. I forgot. > 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. Right. Hmm. I missed that completely when I thought about prune --expire. Sorry, Dscho -- 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