Re: [PATCH v2 4/9] builtin/maintenance: make the geometric factor configurable

[Patrick Steinhardt <ps@pks.im>]

On Thu, Oct 23, 2025 at 03:33:47PM -0400, Taylor Blau wrote:
> On Tue, Oct 21, 2025 at 04:13:26PM +0200, Patrick Steinhardt wrote:
> > The geometric repacking task uses a factor of two for its geometric
> > sequence, meaning that each next pack must contain at least twice as
> > many objects as the next-smaller one. In some cases it may be helpful to
> > configure this factor though to reduce the number of packfile merges
> > even further, e.g. in very big repositories. But while git-repack(1)
> > itself supports doing this, the maintenance task does not give us a way
> > to tune it.
> >
> > Introduce a new "maintenance.geometric-repack.splitFactor" configuration
> > to plug this gap.
> 
> Interesting, this wasn't exactly what I had in my mind when reading the
> last round, but I think this is worth doing on its own. My apologies for
> being ambiguous in my earlier message :-s.
> 
> I was suggesting that we have a repack.geometricFactor configuration
> variable that defaulted to two, could be overridden by --geometric=<n>,
> such that we could start doing "git repack --geometric" without having
> to write "=2" every time.
> 
> I think that that is probably still a useful thing to do in and of
> itself, but this change doesn't preclude our ability to do that, since
> it just overwrites what we pass in to 'git repack' when calling it from
> within the maintenance context.

Yeah, I understood that suggestion, but I still think that in the
context of this series here it makes more sense to piggy back onto
git-maintenance(1) itself so that we're in line with the other tasks
that we have. All of them are configurable via "maintenance.*.foobar"
knobs, so I wanted to have the same architecture for the geometric task,
as well.

But as you say, this doesn't mean that we cannot introduce a config for
git-repack(1) at a later point in time, and I also believe that this may
be a useful addition indeed. I guess the order of precedence would be
that "repack.geometricFactor" is overridden by
"maintenance.geometric-repack.splitFactor", as the latter is more
specific.

Thanks!

Patrick