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. -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html