Re: What happens when the repository is bigger than gc.autopacklimit * pack.packSizeLimit?

From: Dale R. Worley <worley@alum.mit.edu>
Date: Aug 29, 2014, 15:47 UTC
Message-ID: <201408291547.s7TFlZ4F002412@hobgoblin.ariadne.com>
In-Reply-To: <xmqqa96pd59s.fsf@gitster.dls.corp.google.com>

> From: Junio C Hamano <gitster@pobox.com>

> But if your definition of the boundary between "small" and "large"
> is unreasonably low (and/or your definition of "too many" is
> unreasonably small), you will always have the problem you found.

I would propose that a pack whose size is "close enough" to packSizeLimit should be assumed to have already been built by repacking, and shouldn't count against autopacklimit.

That's easy to implement, and causes the desirable result that "git gc --auto" isn't triggerable immediate after repacking.

Of course, eventually there will be enough loose objects, and everything will get repacked (even the "full" packs). But that will happen only occasionally.

That does leave open the question of what is "close enough". Off the top of my head, a pack which is larger than packSizeLimit minus (the size limit for files we put in packs) can be considered "full" in this test.

Then again, maybe the solution is to just set autopacklimit very high, perhaps even by default -- in real use, eventually the gc.auto test will be triggered.

Dale