Re: sequencer status
Le 24/08/2017 à 11:43, Matthieu Moy a écrit : > Christian Couder 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
Re: sequencer status
Christian Couder 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
Le 23/08/2017 à 19:57, Junio C Hamano a écrit : > Nicolas Morey-Chaisemartin 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
Le 23/08/2017 à 18:40, Christian Couder a écrit : > Hi, > > On Wed, Aug 23, 2017 at 10:10 AM, Nicolas Morey-Chaisemartin > 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 >> exectrue >> picke54d993 Fourth commit >> exectrue >> *pick b064629 Third commit >> exectrue >> pick174c933 Second commit >> onto773cb23 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 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
Hi, On Wed, Aug 23, 2017 at 10:10 AM, Nicolas Morey-Chaisemartin 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 > exectrue > picke54d993 Fourth commit > exectrue > *pick b064629 Third commit > exectrue > pick174c933 Second commit > onto773cb23 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.
