From: Taylor Blau <me@ttaylorr.com>
Date: Fri, 24 Oct 2025 19:02:17 GMT
Subject: Re: [PATCH v2 4/9] builtin/maintenance: make the geometric factor configurable
Message-ID: <aPvNOS2JXEHNHn28@nand.local>
In-Reply-To: <aPsSbt0pK4sbmVQj@pks.im>

On Fri, Oct 24, 2025 at 07:45:18AM +0200, Patrick Steinhardt wrote:
> 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.

Yeah, I agree with all of that. From maintenance's perspective, it reads
the value of maintenance.geometric-repack.splitFactor and uses that as a
command-line argument when invoking repack with '--geometric=<n>'

'repack' should of course be oblivious to all of that, and whatever
value it reads from 'repack.geometricFactor' should be the default when
--geometric is passed without a value.

It is a little too bad that we can't say, "all geometric repacking should
use a factor of 3" by default easily, since that would require
maintenance having to read the value of 'repack.geometricFactor' itself,
but I think that's a trade-off that I can live with.

Sounds like this is all good #leftoverbits.

Thanks,
Taylor