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 -- 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