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:36 UTC
Message-ID: <CAA0xjto++XQ6SZVfr5hWq2+CzeBsqSmTOLq_5UvL5s-0HDzaxw@mail.gmail.com>
In-Reply-To: <d09ef622-1398-4e38-8a04-8542e7347a98@gmail.com>

Hi Phillip,

On 07/09/2026 15:25, Phillip Wood wrote:

>      The merge backend which is also used by "git cherry-pick" and "git
>      revert" does not run it when it finishes.
>
> would be clearer to me

Yes, I'll use that.

> Like Patrick I cannot understand what this is saying, let alone whether
> it is saying anything useful.

I've spelled it out in my reply to Patrick and will rewrite the message that way.

>      Run "git maintenace --auto" at the end of all sequencer operations,
>      ...
>
> would be clearer to me

That too.

> Anyway this change is at the end of pick_commits(), just before we
> finish so looks like the right place to call run_auto_maintenance()

Patrick would rather have one exit shared by both rebase backends. In my reply to him I've proposed moving the call out of the sequencer into builtin/rebase.c and builtin/revert.c, the way am.c leaves it to rebase.c today. Say if you'd rather keep it here.

Show 5 quoted lines

> It is a shame the single pick variants of "git cherry-pick" and "git
> revert" do not share the same code path as the multiple pick variants.
> continue_single_pick() runs "git commit" without calling
> run_git_commit() which is also unfortunate, but means that we could just
> rely and "git commit" to call run_auto_maintenance() for us.

That works until the next patch, which turns auto maintenance off in every command the sequencer spawns, this "git commit" included. So somebody has to run it afterwards. With the call in builtin/revert.c, cherry-pick does that itself once the continue returns.

> Do we want to assert that we don't run auto maintenance up to this point?

Yes, I'll add that, and the next patch will extend this test instead of adding its own.

> Using test_grep here would mean we get some useful test output if there
> are not matches in the file. Without that test_line_count just says the
> line count didn't match and prints an empty file.

Will do.

Thanks, Thomas