Re: git auto-repack is broken...
- From
Jeff King <peff@peff.net>
- Date
- Dec 8, 2011, 00:49 UTC
- 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:
Show 10 quoted lines
> > 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