Re: [PATCH 2/8] revert: decouple sequencer actions from builtin commands

Ramkumar Ramachandra wrote:

We'd be prematurely locking ourselves into a design where we can't
tell which top-level command issued the continue/ abort

The .git/sequencer/todo file already doesn't record which top-level
command initiated the sequence and doesn't seem to operate under a
model in which that is a useful question.  Honestly, that's my only
objection to the "git revert --continue during git cherry-pick" check.

I think it is not premature to think about whether that matters.  I've
already said a little about related cases where it seemed to matter
but there was instead something else at play.  Can you offer some
examples of how people might use the "git cherry-pick" / "git revert"
commands and get stuck or run into trouble, and how git can help them?

[...]

                                                          My sincere
suggestion is to procrastinate the problem until we have a tighter
usecase (a new top-level command or action added, for instance).

Thinking carefully about sequencer use cases also seems like a good
idea.  Is it intended that "git am" and "git rebase" should be
reimplemented on top of the sequencer?  Do you have goals in mind for
commands like "git sequence --step" that could be used to examine,
influence, and carry out git's idea of what should happen next?

If we have no use case, then there's no reason to change the code.  It
already works[*] for cherry-pick and revert.  I think we shouldn't be
moving this code to sequencer.c or cleaning up the API to suit other
commands (e.g., introducing two ways to sane "am I picking or
reverting") without having one in mind.

[*] Modulo bugs and some missing features such as --skip.