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:

quoted

On Tue, Oct 21, 2025 at 04:13:26PM +0200, Patrick Steinhardt wrote:

quoted

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