Re: [PATCH v2 2/3] sequencer: run auto maintenance once a sequence is done

From: Thomas Bachem <mail@thomasbachem.com>
Date: Sep 7, 2026, 16:35 UTC
Message-ID: <CAA0xjtqy3jOPWAGL9Cr0B+VnHAkZF0=cVCxKNqMiVJpfbdpomA@mail.gmail.com>
In-Reply-To: <ap5yVFNEFm2vdP1B@pks.im>

Hi Patrick,

On 07/09/2026 10:14, Patrick Steinhardt wrote:

> This paragraph just doesn't parse for me, it's really hard to tell what
> it even wants to say.

Sorry, I'll rewrite it. What I meant: the apply backend runs auto maintenance from finish_rebase() when it is done. The merge backend, cherry-pick and revert create their commits in process and never run it themselves. It only runs when they spawn a command that runs it anyway: "git commit" for an edited message or a resolved conflict, "git merge" for an octopus merge or a custom strategy in "rebase -r", or a git command in an exec. So a clean sequence never runs it, and one with conflicts runs it after each resolution, in the middle of the sequence.

> Besides moving stuff around to prep for the next commit, what does this
> change? Like, do we now run the command in cases where we didn't before?
> And if so, what are the consequences of doing so?

Yes. After this patch every sequence that finishes runs it at the end, like a "git commit" or an apply backend rebase does. The next patch stops the runs in the middle, so it ends up as one run per sequence. The case that changes is a sequence with no conflict to resolve and no message to edit. Such a sequence never ran it at all, so its loose objects waited for the next commit. It is the same "git maintenance run --auto --detach" as after a commit, so it runs in the background and does nothing unless a threshold is met. I'll put that in the message.

Show 5 quoted lines

> It's surprisingly many sites where you add the call to
> `run_auto_maintenance()`. My hope was that there is a single exit path
> somewhere that is used by both the "apply" and "merge" strategy that we
> could adapt to unify when exactly we run auto-maintenance across both
> backends.

There is none inside the sequencer. run_specific_rebase() calls finish_rebase() for the apply backend only, "merge backend cleans up after itself" as the comment there says. Sequences end inside pick_commits(), and a single cherry-pick or revert never creates sequencer state at all and returns straight to builtin/revert.c. That is where the three sites come from.

I could instead do what the apply backend already does. am.c skips maintenance in rebasing mode and leaves it to rebase.c. If the sequencer leaves it to its callers the same way, run_specific_rebase() runs it for the merge backend too, once its state directory is gone, and run_sequencer() in builtin/revert.c runs it for cherry-pick and revert. Every entry into the merge backend returns through run_specific_rebase(), --continue and --skip included, so nothing is missed. The sequencer then never runs it, the change is in the two builtins only, and the rule is short: the command runs it once when it is done, and nothing it spawns does. Is that what you had in mind?

Thanks, Thomas