Re: git-gc doesn't clean up leftover objects after git-filter-branch unless you clone first

From: Avery Pennarun <apenwarr@gmail.com>
Date: Apr 23, 2008, 18:36 UTC
Message-ID: <32541b130804231136n73127cb9rea242981da28ac47@mail.gmail.com>
In-Reply-To: <7vve28sdys.fsf@gitster.siamese.dyndns.org>

On 4/23/08, Junio C Hamano <gitster@pobox.com> wrote:

Show 19 quoted lines

> "Avery Pennarun" <apenwarr@gmail.com> writes:
>
>  > This question has come up at least once a week since I subscribed to
>  > the list.  I can think of these solutions:
>  >
>  > - Add a note to the git-gc and/or git-repack man page about how hidden
>  > refs can impact the cleanup.
>  >
>  > - Add an option to make git-clone *not* hardlink stuff; its different
>  > behaviour for hardlinking vs. file:// seems to be very confusing.
>  >
>  > - Make git-gc give a warning when there are some objects that are only
>  > referenced via the reflog or refs/original.  (I suspect this would
>  > trigger too often though.)
>  >
>  > - Give git-gc a "really, I'm serious" option that makes it ignore the
>  > reflog and refs/original.
>
> - Teach people that leftover cruft is nothing to worry about.

I think any option that starts with "teach people" will not reduce FAQ traffic to the list :) But maybe we could remind people of this somewhere prominent. The git-filter-branch man page?

That said, I think I know why people are concerned about the cruft: it's for the same reason I was when I first tried git-filter-branch to get rid of some gigantic files after importing from svn, to cut the size of a clone from >1GB to <100MB. It's impossible to see if I've succeeded or not unless I make an actual clone, and even *then* I was misled at first because making a local clone is clever and avoids doing any work.

Avery