Re: git auto-repack is broken...

From: Jeff King <peff@peff.net>
Date: Dec 2, 2011, 17:45 UTC
Message-ID: <20111202174546.GA24093@sigill.intra.peff.net>
In-Reply-To: <7vobvqoozr.fsf@alter.siamese.dyndns.org>

On Fri, Dec 02, 2011 at 09:35:52AM -0800, Junio C Hamano wrote:

Show 11 quoted lines

> Jeff King <peff@peff.net> writes:
> 
> > When the objects become unreferenced, we eject them from the pack into
> > loose form again. If they don't become referenced in the 2-week window,
> > they get pruned then. So yes, you drop the age information, but they do
> > eventually go away.
> 
> If you update gc/repack -A to put them in a separate pack, then you would
> never be able to get rid of them, no? You pack, then eject (which gives
> them a fresher timestamp), then notice that you are within the 2-week window
> and pack them again,...

But we shouldn't be packing totally unreferenced objects. Barring bugs, the life cycle of such an object should be something like:

  1. Object X is created on branch 'foo'.

  2. Branch 'foo' is deleted, but its commits are still in the HEAD
     reflog, referencing X.

  3. 90 days pass (actually, I think this might be the 30-day
     expire-unreachable time)

  4. "git gc" runs "git repack -Ad", which will eject X from the pack
     into a loose form (because it is not becoming part of the new pack
     we are writing).

  5. Two weeks pass.

  6. "git gc" runs "git prune --expire=2.weeks.ago", which removes the
     object.

"gc" runs between (4) and (6) will not re-pack the object, because it remains unreferenced.

I think things might be slowed somewhat by "gc --auto", which will not do a "repack -A" until we have too many packs. So steps (3) and (4) are really more like "gc runs git-repack without -A" 50 times, and then we finally run "git repack -A".

-Peff