sequencer status

sequencer status

[Nicolas Morey-Chaisemartin]

Hi,

I've created a small tool to display the current sequencer status.
It mimics what Magit does to display what was done and what is left to do.

As someone who often rebase large series of patches (also works with am, revert, cherry-pick), I really needed the feature and use this daily.

It's available here:
https://github.com/nmorey/git-sequencer-status
SUSE and Fedora packages are available here:
https://build.opensuse.org/package/show/home:NMoreyChaisemartin:git-tools/git-sequencer-status

It's not necessary very robust yet. Most of the time I use simple rebase so there are a lot of untested corner cases.

Here is an example output:
$ sequencer-status
# Interactive rebase: master onto rebase_conflict
exec    true
pick    e54d993 Fourth commit
exec    true
*pick   b064629 Third commit
exec    true
pick    174c933 Second commit
onto    773cb23 Alternate second


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 ?

Nicolas

Re: sequencer status

[Christian Couder]

Hi,

On Wed, Aug 23, 2017 at 10:10 AM, Nicolas Morey-Chaisemartin
<nicolas@morey-chaisemartin.com> wrote:
> Hi,
>
> I've created a small tool to display the current sequencer status.
> It mimics what Magit does to display what was done and what is left to do.
>
> As someone who often rebase large series of patches (also works with am, revert, cherry-pick), I really needed the feature and use this daily.

Yeah, many people use the interactive rebase a lot so I think it could
be very interesting.

> It's available here:
> https://github.com/nmorey/git-sequencer-status
> SUSE and Fedora packages are available here:
> https://build.opensuse.org/package/show/home:NMoreyChaisemartin:git-tools/git-sequencer-status
>
> It's not necessary very robust yet. Most of the time I use simple rebase so there are a lot of untested corner cases.
>
> Here is an example output:
> $ sequencer-status
> # Interactive rebase: master onto rebase_conflict
> exec    true
> pick    e54d993 Fourth commit
> exec    true
> *pick   b064629 Third commit
> exec    true
> pick    174c933 Second commit
> onto    773cb23 Alternate second

It is displaying the steps that have already been performed, right?
I wonder if people might want more about the current step (but maybe
that belongs to `git status`) or perhaps the not yet performed states
(and maybe even a way to edit the todo list?)

> Two questions:
> - Could this be a candidate for contrib/ ?

It seems to me that these days we don't often add new tools to contrib/.

> - Would it be interesting to add the relevant code to sequencer.c so that all sequencer based commands could have a --status option ?

Yeah, it's probably better if it's integrated in git, either as a
--status option in some commands, or perhaps as an option of `git
status`.

Thanks,
Christian.

Re: sequencer status

[Junio C Hamano]

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".

Re: sequencer status

[Nicolas Morey-Chaisemartin]

Le 23/08/2017 à 18:40, Christian Couder a écrit :
> Hi,
>
> On Wed, Aug 23, 2017 at 10:10 AM, Nicolas Morey-Chaisemartin
> <nicolas@morey-chaisemartin.com> wrote:
>> Hi,
>>
>> I've created a small tool to display the current sequencer status.
>> It mimics what Magit does to display what was done and what is left to do.
>>
>> As someone who often rebase large series of patches (also works with am, revert, cherry-pick), I really needed the feature and use this daily.
> Yeah, many people use the interactive rebase a lot so I think it could
> be very interesting.
>
>> It's available here:
>> https://github.com/nmorey/git-sequencer-status
>> SUSE and Fedora packages are available here:
>> https://build.opensuse.org/package/show/home:NMoreyChaisemartin:git-tools/git-sequencer-status
>>
>> It's not necessary very robust yet. Most of the time I use simple rebase so there are a lot of untested corner cases.
>>
>> Here is an example output:
>> $ sequencer-status
>> # Interactive rebase: master onto rebase_conflict
>> exec    true
>> pick    e54d993 Fourth commit
>> exec    true
>> *pick   b064629 Third commit
>> exec    true
>> pick    174c933 Second commit
>> onto    773cb23 Alternate second
> It is displaying the steps that have already been performed, right?
> I wonder if people might want more about the current step (but maybe
> that belongs to `git status`) or perhaps the not yet performed states
> (and maybe even a way to edit the todo list?)

Yes it is displaying all steps.
The line beginning by '*' is the current step.

Trying to "guess" what is happening on the current step is quite hard. Between conflict, empty commits, stopped for amending and other, it's a lot of cases to handle.
I'd rather have git-status deal with it (and you get your standard log/error fro your rebase/cp/am/revert command too).
The idea here is really to find out where you are in your operation sequence.

I've had a 700 patch series to reapply on a different subtree. Took me 3 days. This script was quite handy. (Also depressing as you can see how much work left there is).

Also if you feel it's missing something you need, I'm accepting PR on github ;)

>> Two questions:
>> - Could this be a candidate for contrib/ ?
> It seems to me that these days we don't often add new tools to contrib/.
>
>> - Would it be interesting to add the relevant code to sequencer.c so that all sequencer based commands could have a --status option ?
> Yeah, it's probably better if it's integrated in git, either as a
> --status option in some commands, or perhaps as an option of `git
> status`.

I'll have a look at what can be done.

Thanks

Nicolas

Re: sequencer status

[Nicolas Morey-Chaisemartin]

Le 23/08/2017 à 19:57, Junio C Hamano a écrit :
> 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".

I like your idea. I'm not sure I have the bandwidth to do this (by myself at least).
If someone (hopefully more familiar with the sequencer code than me) wants to work on this, I'd gladly help.

Nicolas

Re: sequencer status

[Matthieu Moy]

Christian Couder <christian.couder@gmail.com> writes:

> It is displaying the steps that have already been performed, right?
> I wonder if people might want more about the current step (but maybe
> that belongs to `git status`) or perhaps the not yet performed states
> (and maybe even a way to edit the todo list?)

Note that 'git status' is already doing this, but shows only 2 items of
each:

$ git status
interactive rebase in progress; onto 3772427
Last commands done (2 commands done):
   pick a48812c some commit title
   exec false
Next commands to do (2 remaining commands):
   pick 9d7835d some other commit
   pick c0e0fa8 one more subject
  (use "git rebase --edit-todo" to view and edit)
You are currently editing a commit while rebasing branch 'master' on '3772427'.
...

The idea was that 2 lines of context is often sufficient, and doesn't
eat too much screen space so it makes sense to show it by default.

I think it makes sense to have another command that shows the whole
sequence, but perhaps it could also be just an option for "git status".

Cheers,

-- 
Matthieu Moy
https://matthieu-moy.fr/

Re: sequencer status

[Nicolas Morey-Chaisemartin]

Le 24/08/2017 à 11:43, Matthieu Moy a écrit :
> Christian Couder <christian.couder@gmail.com> writes:
>
>> It is displaying the steps that have already been performed, right?
>> I wonder if people might want more about the current step (but maybe
>> that belongs to `git status`) or perhaps the not yet performed states
>> (and maybe even a way to edit the todo list?)
> Note that 'git status' is already doing this, but shows only 2 items of
> each:
>
> $ git status
> interactive rebase in progress; onto 3772427
> Last commands done (2 commands done):
>    pick a48812c some commit title
>    exec false
> Next commands to do (2 remaining commands):
>    pick 9d7835d some other commit
>    pick c0e0fa8 one more subject
>   (use "git rebase --edit-todo" to view and edit)
> You are currently editing a commit while rebasing branch 'master' on '3772427'.
> ...
>
> The idea was that 2 lines of context is often sufficient, and doesn't
> eat too much screen space so it makes sense to show it by default.
>
> I think it makes sense to have another command that shows the whole
> sequence, but perhaps it could also be just an option for "git status".
>
> Cheers,
>

But this is only for interactive rebase.
It might be worth adding a parameter for this, but I'd also like to see this feature for all rebase/cp/revert

Nicolas