Nicolas Morey-Chaisemartin <nicolas@xxxxxxxxxxxxxxxxxxxxxx> writes: > Two questions: > - Could this be a candidate for contrib/ ? > - Would it be interesting to add the relevant code to sequencer.c > so that all sequencer based commands could have a --status option I actually think we would want a "git sequencer" command, which can be fed an arbitrary instruction sheet created by a third-party and told to "run" it. A new command $cmd that wants to rewrite history (like "rebase -i", "cherry-pick A..B", etc. do) can only concentrate on preparing the sequence of instructions and then internally invoke "git sequencer run" until it gives the control back to the end user. When the user tells $cmd to continue, it can relay that request to "git sequencer continue" under the hood. Once its use is established, it might be even possible to let users run "git sequencer continue", bypassing frontends for individual commands, e.g. "git cherry-pick --continue", etc., but I do not know if that is generally a good idea or not. In any case, having such a front-end will help third-party scripts that want to build a custom workflow using the sequecing machinery we have. And in such a world, we would need "git sequencer status" command to give us where in a larger sequence of instrutions we are. So I tend to think this should be part of the core, not contrib/, and should become part of a new command "git sequencer".
