Re: [PATCH] odb/files: be less aggressive with geometric repacking

[Patrick Steinhardt <ps@pks.im>]

On Tue, Aug 18, 2026 at 05:34:54PM -0500, Justin Tobler wrote:
> On 26/08/12 07:44AM, Patrick Steinhardt wrote:
> > On Tue, Aug 11, 2026 at 03:44:12PM -0500, Justin Tobler wrote:
> > > Increasing the loose object threshold here to be more conservative seems
> > > like a reasonable approach. I'm not sure exactly why 6700 was chosen
> > > here. 6700 / 256 ~= 26.2 which means "objects/17/" would have to contain
> > > at least 27 objects before repacking is triggered. That is certainly
> > > much more conservative. I see that 6700 has also been chosen else where
> > > in the codebase as the threshold too. It might be nice to explain the
> > > reasoning a bit more in the commit message though.
> > 
> > Hmm, don't I already do that? In the paragraph you're responding to I'm
> > saying that git-gc(1) already had that default forever, so I'm adjusting
> > our heuristic to match that.
> 
> I think I was just curious as to why 6700 was the chosen number for
> git-gc(1) as well, but its probably just good to be consistent here. I
> think this patch is fine as is.

That's a good question. It has been introduced all the way back in
2c3c439947 (Implement git gc --auto, 2007-09-05), but that commit does
not mention any reasoning for the 6700 limit either.

Digging in history a bit surfaces this nugget [1]. So the limit was
chosen so that git-gc(1) would not trigger for a fully unpacked Git
v0.99, would trigger for v1.0, but not triggering when doing an
incremental gc after going from v0.99 to v1.0. This is of course quite
arbitrary, but as the mail points out, "[t]he default threshold is
arbitrarily set by yours truly" (Junio).

Patrick

[1]: https://lore.kernel.org/git/7vr6lcj2zi.fsf@gitster.siamese.dyndns.org/