Subject: Re: [PATCH 0/7] builtin/maintenance: implement missing tasks compared to git-gc(1)

From: Patrick Steinhardt <[email-masked]>
Date: Wed, 30 Apr 2025 09:08:06 +0200

On Tue, Apr 29, 2025 at 04:02:18PM -0400, Derrick Stolee wrote:
> On 4/25/2025 3:29 AM, Patrick Steinhardt wrote:
> 
> > Right now, git-maintenance(1) still executes git-gc(1). With these last
> > gaps plugged though we can in theory fully replace git-gc(1) with finer
> > grained tasks without losing any functionality. The benefit is that it
> > becomes possible for users to have finer-grained control over what
> > exactly the maintenance does.
> > 
> > This patch series doesn't do that yet, but only implements whatever is
> > needed to get there.
> 
> Thanks for putting this together. I think this is a noble goal, allowing
> users and system administrators more options to fine-tune the best ways to
> optimize their repos.
> 
> I wonder if any of these fine-grained steps would be valuable to add to
> the default background maintenance schedule (perhaps as a follow-up)?

I think so, yes. My immediate goal is to change `git maintenance run
--auto` to not run git-gc(1) by default anymore, but to instead have it
run the fine-grained steps. But we should probably at the same time also
adapt the background maintenance to use the same fine-grained tasks so
that the outcome matches.

My idea would be that we implement all of this via high-level strategies
that get honored by scheduled, auto and explicit maintenance alike. We
already have the "incremental" strategy, but there are other strategies
that might make sense to introduce. There should be at least one
strategy that achieves the same as git-gc(1) does right now, but there's
probably more opportunities here to have e.g. a "geometric" strategy.

Users can then pick whatever strategy works best for them, with us
providing a good default as well as rationale why we recommend one
strategy over another. Furthermore, expert users can of course tweak
these strategies even further by explicitly configuring which of the
fine-grained tasks should run.

Thinking ahead a bit, one might even be prompted to auto-select
strategies based on repository properties. A tiny repository likely does
not need multi-pack indices and cruft packs, but a huge behemoth like
the Chromium repository probably would benefit. But that is an iteration
that one can think about in the future.

Patrick