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

[Patrick Steinhardt <ps@pks.im>]

On Mon, Sep 07, 2026 at 06:35:20PM +0200, Thomas Bachem wrote:
> On 07/09/2026 10:14, Patrick Steinhardt wrote:
[snip]
> > 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?

Maybe. The question is what kind of impact it would have on other
subsystems. I think the most important part that I'm after is that the
commit message explains design decisions like this, as it gives the
reader the required context to be able to evaluate the patch.

And please stay mindful of LLM-generated commit messages. For most of
the part they are just completely useless as they tend to ramble without
conveying any useful information. The commit message is the place where
you yourself sell the change to us, and by explaining the changes well
you demonstrate that you understand what you're sending to the mailing
list.

An LLM-generated commit message on the other side demonstrates nothing
like that. So in many cases, it's actively hurting your own mission as
people do notice that it's not generated by humans.

It's fine to use LLMs to help you with drafting the commit message. But
what we're asking is that you double or even triple check what was
generated and whether the generated message (1) makes sense and (2) is
understandable by a normal human being.

Thanks!

Patrick