Re: [PATCH v4 2/3] rebase, cherry-pick, revert: run auto maintenance when done

From: Patrick Steinhardt <ps@pks.im>
Date: Sep 11, 2026, 07:34 UTC
Message-ID: <aqOvAttPrhUIP_7U@pks.im>
In-Reply-To: <b7b97262f27782f3271369115496c67f9774b8b2.1788942331.git.gitgitgadget@gmail.com>

On Wed, Sep 09, 2026 at 08:25:30AM +0000, Thomas Bachem via GitGitGadget wrote:

Show 7 quoted lines

> From: Thomas Bachem <mail@thomasbachem.com>
> 
> "git cherry-pick", "git revert" and the merge backend of "git rebase"
> create their commits in process, so auto maintenance runs only when
> they spawn a command that runs it, like the "git commit" for a
> resolved conflict. A sequence thus runs it in the middle, after each
> resolution, or never.

This paragraph still doesn't make a lot of sense. How about:

  Commands that use the sequencer with the "merge" backend, like
  git-cherry-pick(1) or git-rebase(1) with "--merge", create their
  commits in-process. Consequently, these commands typically don't
  execute auto-maintenance at all. The only exception is when a conflict
  happens, as the user would have to manually commit the result via
  git-commit(1), and that command triggers auto-maintenance for us.

  In contrast to that, the "apply" backend of the sequencer _does_ run
  auto-maintenance after it has processed the sequence of commits. And
  this is a sensible thing to do: after all, we may just have written
  lots of objects, so chances are high that we have something to clean
  up now.

  Adapt users of the "merge" backend to do the same.

  Unfortunately, there is no single exit point for this backend where we
  could add a call to `run_auto_maintenance()`. While one might expect
  that we could simply trigger auto-maintenance in `pick_commits()` and
  call it a day, a single pick as it is performed by e.g. git-revert(1)
  never executes that function. So instead, manually trigger
  auto-maintenance at several sites.

This last paragraph though...

Show 9 quoted lines

> Run it once when the sequence is done, like the apply backend does.
> 
> The sequencer has no single place where every sequence ends: a
> sequence of several commits ends in pick_commits(), a single pick
> returns as soon as its commit is made, and "--continue" and "--skip"
> have entry points of their own. Run it from the two builtins that
> start or continue a sequence instead: run_specific_rebase() once the
> sequencer has returned and removed its state directory, and
> run_sequencer() after a successful pick, "--continue" or "--skip".

... is still kind of dubious. As far as I can see, almost everything does end up in `pick_commits()` eventually:

  - git-revert(1) does via `run_sequencer()`, which calls
    `sequencer_pick_revisions()`, and that calls `pick_commits()`.

  - git-cherry-pick(1) does via the same call chain.

  - git-rebase(1) does so via `do_interactive_rebase()`, which calls
    `complete_action()`, and that function calls `pick_commits()`. Or
    alternatively via `sequencer_continue()`, which again calls it.

  - Skipping commits via "--skip" eventually ends up in
    `sequencer_continue()`, and that calls `pick_commits()`.

The only exception that I could spot is when we abort the sequencer. But I'd rather have us call auto-maintenance when `pick_commits()` is done and when we abort rather than having every user of the sequencer do it manually.

Or am I missing something here?

Patrick