Re: [PATCH 1/2] sequencer: run auto maintenance once a rebase is done

[Phillip Wood <phillip.wood123@gmail.com>]

Hi Thomas

On 04/09/2026 08:53, Thomas Bachem via GitGitGadget wrote:
> From: Thomas Bachem <mail@thomasbachem.com>
> 
> The apply backend runs "git maintenance run --auto" from
> finish_rebase() once it has applied its patches, and so does "git am"
> on its own. The merge backend reaches finish_rebase() only on the
> paths both backends share in builtin/rebase.c: an abort, a branch
> that is already up to date, and a fast-forward. A rebase that
> replays commits never runs maintenance at its end. It creates most
> of its commits in process, and only the "git commit" it spawns for a
> resolved, reworded or squashed pick, the "git merge" a "rebase -r"
> spawns for an octopus merge or with a strategy, and whatever an exec
> command runs kick maintenance off, in the middle of the rebase. Run
> it where the sequencer finishes a rebase, after the autostash is
> applied, as finish_rebase() does, so that both backends end a rebase
> the same way, and so that the next commit can keep it out of the
> commands a rebase spawns. builtin/rebase.c could run it instead once
> run_sequencer_rebase() returns, but the sequencer is where the rebase
> finishes, and the autostash and the state cleanup that surround the
> run in finish_rebase() are there as well. prepare_auto_maintenance()
> closes the object database before the spawn, so the sequencer holds
> nothing a repack would need to replace.

It would be nice if the two backends shared more of the cleanup code, I 
don't think there is a good reason for them not to share the code that 
copies notes, applies the autostash and switches HEAD back to the 
branch, but that is outside the scope of this change. So adding a 
separate call to the sequencer code seems reasonable. I wonder if we 
should do this for cherry-pick and revert as well; certainly cherry-pick 
can create a lot of loose objects and does not necessarily call "git 
commit". If cherry-pick does call "git commit" and trigger background 
maintenance it is susceptible to the same problems as rebase, so we 
should probably treat them the same.

Thanks

Phillip

> 
> Assisted-by: Claude Fable 5.1
> Signed-off-by: Thomas Bachem <mail@thomasbachem.com>
> ---
>   sequencer.c                | 5 +++++
>   t/t3418-rebase-continue.sh | 8 ++++++++
>   2 files changed, 13 insertions(+)
> 
> diff --git a/sequencer.c b/sequencer.c
> index 65afd100d9..f58ad254be 100644
> --- a/sequencer.c
> +++ b/sequencer.c
> @@ -5297,6 +5297,11 @@ cleanup_head_ref:
>   			run_hooks_opt(r, "post-rewrite", &hook_opt);
>   		}
>   		apply_autostash(rebase_path_autostash());
> +		/*
> +		 * We ignore errors in 'git maintenance run --auto', since the
> +		 * user should see them.
> +		 */
> +		run_auto_maintenance(r, opts->quiet);
>   
>   		if (!opts->quiet) {
>   			if (!opts->verbose)
> diff --git a/t/t3418-rebase-continue.sh b/t/t3418-rebase-continue.sh
> index cb5c3a1cb5..2c34cf8a01 100755
> --- a/t/t3418-rebase-continue.sh
> +++ b/t/t3418-rebase-continue.sh
> @@ -395,4 +395,12 @@ test_orig_head () {
>   test_orig_head --apply
>   test_orig_head --merge
>   
> +test_expect_success 'rebase runs auto maintenance at its end' '
> +	git checkout -b one-exec main^ &&
> +	test_commit F4 &&
> +	test_must_fail git rebase -x false main &&
> +	GIT_TRACE2_EVENT="$(pwd)/finish.txt" git rebase --continue &&
> +	test_subcommand_flex git maintenance run --auto <finish.txt
> +'
> +
>   test_done