Hi,
On Fri, 5 Oct 2007, Andreas Ericsson wrote:
> 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@xxxxxxxxxxxxx>
> > ---
> >
> > 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).
It will so, in due time. Reflogs have an expiry date, and will be culled
by git gc --auto. So if you dcommit often (which I do), the objects will
be pruned, eventually.
Ciao,
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
