Re: sequencer status

[Junio C Hamano <gitster@pobox.com>]

Nicolas Morey-Chaisemartin <nicolas@morey-chaisemartin.com> 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".