From: Jeff King <peff@peff.net>
Date: Thu, 08 Dec 2011 00:49:31 GMT
Subject: Re: git auto-repack is broken...
Message-ID: <20111208004931.GB23015@sigill.intra.peff.net>
In-Reply-To: <CA+sFfMdeVoz8XU5j4hNn1qCHHzaiDi0Bw=QbbuU3cwT9mMPZOA@mail.gmail.com>

On Sat, Dec 03, 2011 at 01:42:22PM -0600, Brandon Casey wrote:

> >  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).
> 
> Actually, it is right here when the newly loosened unreferenced
> objects will be deleted.  Objects ejected from a pack _are_ given the
> timestamp of the pack they were ejected from.  So, if the pack is
> older than two weeks (90 days in your example), then so will be the
> loosened objects, and git prune will delete them when called by git
> gc.

Thanks, I didn't notice that when looking at the code.

> Decreasing gc.pruneExpire as you suggested should make it much less
> likely to run into this problem.

I'd be more comfortable with that solution if we had data on what the
timestamps look like when it actually happens (e.g., an "ls -lR" listing
of a repository that in practice is wanting to auto-gc too often).

> I wonder if it is worth trying to limit how often gc --auto is run to
> not be more often than gc.pruneExpire or something.  If we modified
> the timestamp that is assigned to fetched packs, maybe we could use
> the pack timestamps as an indicator of how recently git gc has run.

I'm worried you run into other corner cases, there. Like a repository
which is generating new, referenced objects at a fast rate (e.g.,
because you're importing something) should trigger auto-gc much sooner
than that, and this rule would prevent it.

-Peff