While looking into the rerere lock race in [1], the "git commit" a rebase
spawns for a resolved pick turned out to be about the only place a rebase
with the merge backend runs auto maintenance, and it runs it against the
rebase itself. Phillip asked for auto maintenance to be kept out of a rebase
altogether [2], and for the merge backend to run it once at the end the way
the apply backend does [3]. Patrick would rather see that discussed on its
own [4], hence this series.

Patch 1 runs auto maintenance where the sequencer finishes a rebase, as the
apply backend does. Patch 2 then passes maintenance.auto=false and gc.auto=0
to the "git commit", "git merge" and exec commands a rebase spawns, so that
a rebase runs it once, at its end. Cherry-pick and revert are left as they
are.

Based on master. Independent of [1], which makes the rerere lock non-fatal:
with both, a rebase neither spawns the gc nor dies on one that something
else spawned.

[1] <pull.2214.git.1788337897490.gitgitgadget@gmail.com>

[2] <ca3b91b6-254c-4b86-adb8-da3217e9f6e7@gmail.com>

[3] <86efb07c-a0ce-49b0-b4eb-7d6b4bbaeccc@gmail.com>

[4] <apkwpKTGaMwTf0Hz@pks.im>

Thomas Bachem (2):
  sequencer: run auto maintenance once a rebase is done
  sequencer: keep auto maintenance out of the commands a rebase spawns

 sequencer.c                | 32 ++++++++++++++++++++++++++++++++
 t/t3418-rebase-continue.sh | 26 ++++++++++++++++++++++++++
 2 files changed, 58 insertions(+)

base-commit: 3cb9185f65410273787f74333cc027d2ea5daada

Submitted-As: https://lore.kernel.org/git/pull.2217.git.1788508426.gitgitgadget@gmail.com