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

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