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:

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.

Thanks!

Patrick