Re: [PATCH 2/2] Run garbage collection with loose object pruning after svn dcommit

> Steven Grimm wrote:
> > git-svn dcommit, by virtue of rewriting history to insert svn revision IDs,
> > leaves old commits dangling.  Since dcommit is already unsafe to run
> > concurrently with other git commands, no additional risk is introduced
> > by making it prune those old objects as needed.
> > 
> > Signed-off-by: Steven Grimm <koreth@midwinter.com>
> > ---
> > 
> > This is in response to a colleague who complained that, after I
> > installed the latest git release, he was getting lots of "too many
> > unreachable loose objects" errors from the new "git gc --auto" run.
> > Those objects turned out to be dangling commits from a year's worth of
> > git-svn usage, since every git-svn commit will abandon at least one
> > existing commit in order to rewrite it with the svn version data.
> > 
> >  git-svn.perl |    6 ++++++
> >  1 files changed, 6 insertions(+), 0 deletions(-)
> > 
> > diff --git a/git-svn.perl b/git-svn.perl
> > index 777e436..be62ee1 100755
> > --- a/git-svn.perl
> > +++ b/git-svn.perl
> > @@ -441,6 +441,12 @@ sub cmd_dcommit {
> >  			}
> >  			command_noisy(@finish, $gs->refname);
> >  			$last_rev = $cmt_rev;
> > +
> > +			# rebase will have made the just-committed revisions
> > +			# unreachable; over time that can build up lots of
> > +			# loose objects in the repo. prune is unsafe to run
> > +			# concurrently but so is dcommit.
> > +			command_noisy(qw/gc --auto --prune/);
> >  		}
> >  	}
> >  }
> 
> I'd be surprised if this would ever prune anything, as git doesn't throw 
> out objects reachable by reflog (or, I assume, any of the objects 
> reachable from objects reachable from reflog).