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

From: Patrick Steinhardt <ps@pks.im>
Date: Apr 30, 2025, 07:08 UTC
Message-ID: <aBHMVm9QIKZwiaBX@pks.im>
In-Reply-To: <3cc1ef7b-40d5-4802-9bf9-ff28824ce563@gmail.com>

On Tue, Apr 29, 2025 at 04:02:18PM -0400, Derrick Stolee wrote:

Show 17 quoted lines

> 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