# New feature discussion: git rebase --status 16 messages from 2013-06-11 to 2013-06-13. Participants: Mathieu Liénard--Mayor, Thomas Rast, John Keeping, Matthieu Moy, Hilco Wijbenga, Linus Torvalds, Célestin Matte, Antoine Pelisse, Junio C Hamano. Thread: https://gitlist.dev/t/34101 ## Mathieu Liénard--Mayor, 2013-06-11 12:35 Subject: New feature discussion: git rebase --status Message-ID: URL: https://gitlist.dev/e/fb379a75c6c1af6dcff2e65bef1f1836%40ensibm.imag.fr ``` (Got the idea from: https://git.wiki.kernel.org/index.php/SmallProjectsIdeas#git_rebase_--status) When in the middle of a rebase, users can be easily confused about what to do, or where they are in the rebase process. All the information is available in .git/rebase-merge/, but I believe it would be helpful to have a command (for example 'git rebase --status') which would explicitely indicate the state of the process. For instance, the output could look like: $ git rebase --status Rebasing my_last_commit onto base_commit Already applied 2 patches: b170635... my_commit_message b170635... my_commit_message Currently applying b170635... my_commit_message 2 patches left to apply: b170635... my_commit_message b170635... my_commit_message Another nice thing could be to improve the output of 'git status' by saying the number of patches left to apply. As an example, it could say: You are currently rebasing (patch 3/5). What do you think? Does the name rebase --status seem appropriate? Should the output be providing more/less information? Thanks =] -- Mathieu Liénard--Mayor, 2nd year at Grenoble INP - ENSIMAG (+33)6 80 56 30 02 ``` ## Thomas Rast, 2013-06-11 12:40 Subject: Re: New feature discussion: git rebase --status Message-ID: <871u8895xh.fsf@linux-k42r.v.cablecom.net> URL: https://gitlist.dev/e/871u8895xh.fsf%40linux-k42r.v.cablecom.net In-Reply-To: ``` Mathieu Liénard--Mayor writes: > (Got the idea from: > https://git.wiki.kernel.org/index.php/SmallProjectsIdeas#git_rebase_--status) > > When in the middle of a rebase, users can be easily confused about > what to do, or where they are in the rebase process. > > All the information is available in .git/rebase-merge/, but I believe > it would be helpful to have a command (for example 'git rebase > --status') which would explicitely indicate the state of the process. > > For instance, the output could look like: > > $ git rebase --status > Rebasing my_last_commit onto base_commit > Already applied 2 patches: > b170635... my_commit_message > b170635... my_commit_message > Currently applying b170635... my_commit_message > 2 patches left to apply: > b170635... my_commit_message > b170635... my_commit_message > > > Another nice thing could be to improve the output of 'git status' by > saying the number of patches left to apply. > As an example, it could say: > You are currently rebasing (patch 3/5). > > What do you think? > Does the name rebase --status seem appropriate? > Should the output be providing more/less information? I think a worthy goal would be to arrange things such that the "here's what you do next" messages are shared between --status and the code that stops. I.e., the same code should generate When you have resolved this problem, run "git rebase --continue". If you prefer to skip this patch, run "git rebase --skip" instead. To check out the original branch and stop rebasing, run "git rebase --abort". in both cases. Naturally --status should also explain how it got into this state, as you outlined above. -- Thomas Rast trast@{inf,student}.ethz.ch ``` ## John Keeping, 2013-06-11 12:55 Subject: Re: New feature discussion: git rebase --status Message-ID: <20130611125521.GL22905@serenity.lan> URL: https://gitlist.dev/e/20130611125521.GL22905%40serenity.lan In-Reply-To: ``` On Tue, Jun 11, 2013 at 02:35:29PM +0200, Mathieu Liénard--Mayor wrote: > (Got the idea from: > https://git.wiki.kernel.org/index.php/SmallProjectsIdeas#git_rebase_--status) > > When in the middle of a rebase, users can be easily confused about > what to do, or where they are in the rebase process. > > All the information is available in .git/rebase-merge/, but I believe > it would be helpful to have a command (for example 'git rebase > --status') which would explicitely indicate the state of the process. > > For instance, the output could look like: > > $ git rebase --status > Rebasing my_last_commit onto base_commit > Already applied 2 patches: > b170635... my_commit_message > b170635... my_commit_message > Currently applying b170635... my_commit_message > 2 patches left to apply: > b170635... my_commit_message > b170635... my_commit_message The one piece of information that I often want is the SHA1 of the commit that is currently being applied. Currently I have to look through my scrollback for the "stopping" message or poke around in .git/. Having that in the output of "git status" would be really nice, but the output format you've posted is a big improvement over what we have at the moment for this case. Actually, the same applies for cherry-pick and revert when they have been given a range - showing the commit that is currently being applied in "git status" would be nice there as well. ``` ## Matthieu Moy, 2013-06-11 13:19 Subject: Re: New feature discussion: git rebase --status Message-ID: URL: https://gitlist.dev/e/vpqbo7c4wen.fsf%40anie.imag.fr In-Reply-To: <20130611125521.GL22905@serenity.lan> ``` John Keeping writes: > The one piece of information that I often want is the SHA1 of the commit > that is currently being applied. Currently I have to look through my > scrollback for the "stopping" message or poke around in .git/. > > Having that in the output of "git status" would be really nice, ... and should be rather easy as it is the content of .git/rebase-merge/stopped-sha Perhaps "git status" could say stg like "(applying 1d3fb08, 2/5)" > output format you've posted is a big improvement over what we have at > the moment for this case. My idea when I wrote the item on the wiki was to keep the a very short summary in "git status", and to put all the information one could whish in a separate command. I'd describe it as a complement more than an improvement ;-). -- Matthieu Moy http://www-verimag.imag.fr/~moy/ ``` ## Hilco Wijbenga, 2013-06-11 17:18 Subject: Re: New feature discussion: git rebase --status Message-ID: URL: https://gitlist.dev/e/CAE1pOi0azF1pFqhU1Dq3qeXXF%2Bn9xBcAnHOHapTDjbNXop0d2g%40mail.gmail.com In-Reply-To: ``` On 11 June 2013 06:19, Matthieu Moy wrote: > John Keeping writes: > >> The one piece of information that I often want is the SHA1 of the commit >> that is currently being applied. Currently I have to look through my >> scrollback for the "stopping" message or poke around in .git/. >> >> Having that in the output of "git status" would be really nice, > > ... and should be rather easy as it is the content of > .git/rebase-merge/stopped-sha > > Perhaps "git status" could say stg like "(applying 1d3fb08, 2/5)" > >> output format you've posted is a big improvement over what we have at >> the moment for this case. > > My idea when I wrote the item on the wiki was to keep the a very short > summary in "git status", and to put all the information one could whish > in a separate command. I'd describe it as a complement more than an > improvement ;-). Having "git status" display (even more) "context sensitive" information during "git rebase" or "git merge" would be very welcome. Please, if at all possible, don't make that a separate command. ``` ## Linus Torvalds, 2013-06-11 17:23 Subject: Re: New feature discussion: git rebase --status Message-ID: URL: https://gitlist.dev/e/CA%2B55aFwtBm2RPwgXNa48zQM7ONCgzOEN2XdA_MeHsGu4%3DBDq5w%40mail.gmail.com In-Reply-To: ``` On Tue, Jun 11, 2013 at 10:18 AM, Hilco Wijbenga wrote: > > Having "git status" display (even more) "context sensitive" > information during "git rebase" or "git merge" would be very welcome. > Please, if at all possible, don't make that a separate command. I agree. The rebase state etc is something that would be much better in "git status" output, and would avoid having people learn about another new flag to random commands. Linus ``` ## Mathieu Liénard--Mayor, 2013-06-12 10:17 Subject: Re: New feature discussion: git rebase --status Message-ID: URL: https://gitlist.dev/e/fa9c12a81ef2e92ba75dd1271d9e0b2d%40ensibm.imag.fr In-Reply-To: ``` After a few hours, here's a quick summary of your opinions: -'git status' should be the command to display the information instead of a --status flag -the SHA1 of the patch being applied currently is a very important information -displaying how we got to this state would be nice I had in mind a slight change in the current status message, just to include the SHA1 and where we're at in the rebasing. It would look like this: $ git status # HEAD detached from ecb9f3e # You are currently editing a832578... my_commit_message [3/5] while rebasing. # (use "git commit --amend" to amend the current commit) # (use "git rebase --continue" once you are satisfied with your changes) # ...... # ...... Now, I'm not sure if we should always display the list of commits already applied and those left to apply. What I mean is that maybe it would be better to make status require a flag to display the two lists. Something like (not sure about the flag's name): $ git status --rebase-state # HEAD detached from ecb9f3e # Already applied 2 patches: # b170635... my_commit_message # b170635... my_commit_message # You are currently editing a832578... my_commit_message [3/5] while rebasing. # 2 patches left to apply: # b170635... my_commit_message # b170635... my_commit_message # (use "git commit --amend" to amend the current commit) # (use "git rebase --continue" once you are satisfied with your changes) # ...... # ...... What do you guys think ? -- Mathieu Liénard--Mayor, 2nd year at Grenoble INP - ENSIMAG (+33)6 80 56 30 02 ``` ## Célestin Matte, 2013-06-12 11:12 Subject: Re: New feature discussion: git rebase --status Message-ID: <51B857B0.5030603@ensimag.fr> URL: https://gitlist.dev/e/51B857B0.5030603%40ensimag.fr In-Reply-To: ``` Le 12/06/2013 12:17, Mathieu Liénard--Mayor a écrit : > Now, I'm not sure if we should always display the list of commits > already applied and those left to apply. What I mean is that maybe it > would be better to make status require a flag to display the two lists. > Something like (not sure about the flag's name): > > $ git status --rebase-state > # HEAD detached from ecb9f3e > # Already applied 2 patches: > # b170635... my_commit_message > # b170635... my_commit_message > # You are currently editing a832578... my_commit_message [3/5] while > rebasing. > # 2 patches left to apply: > # b170635... my_commit_message > # b170635... my_commit_message > # (use "git commit --amend" to amend the current commit) > # (use "git rebase --continue" once you are satisfied with your changes) > # ...... > # ...... > > What do you guys think ? I agree. When you're in the process of rebasing a big list of commits, it would produce a lot of not-so-useful output, when what you want to see is, most of the time, which commit you are currently editing. So, in my opinion, whole lists should not be displayed by default. Now, if I could suggest an improvement over that list: when you rebase some commits, I'm quite sure the history of what you already did is stored somewhere since you can revert it which git rebase --abort. It would be nice to improve that list by displaying these informations, like: $ git status --rebase-state # HEAD detached from ecb9f3e # Already applied 4 patches: # b170635... my_commit_message # b170635... my_commit_message # new: b170635... my_commit_message # modified: b170635... my_commit_message # reworded: b170635... my_commit_message # You are currently editing a832578... my_commit_message [5/8] while rebasing. # 2 patches left to apply: # b170635... my_commit_message # b170635... my_commit_message # (use "git commit --amend" to amend the current commit) # (use "git rebase --continue" once you are satisfied with your changes) # ...... # ...... I have no idea how complicated it would be to do that, though. What do you think? -- Célestin Matte ``` ## Mathieu Liénard--Mayor, 2013-06-12 11:23 Subject: Re: New feature discussion: git rebase --status Message-ID: <3cafe99fe3b868e6fc025110d324b9c8@ensibm.imag.fr> URL: https://gitlist.dev/e/3cafe99fe3b868e6fc025110d324b9c8%40ensibm.imag.fr In-Reply-To: <51B857B0.5030603@ensimag.fr> ``` Le 2013-06-12 13:12, Célestin Matte a écrit : > Le 12/06/2013 12:17, Mathieu Liénard--Mayor a écrit : >> Now, I'm not sure if we should always display the list of commits >> already applied and those left to apply. What I mean is that maybe >> it >> would be better to make status require a flag to display the two >> lists. >> Something like (not sure about the flag's name): >> >> $ git status --rebase-state >> # HEAD detached from ecb9f3e >> # Already applied 2 patches: >> # b170635... my_commit_message >> # b170635... my_commit_message >> # You are currently editing a832578... my_commit_message [3/5] while >> rebasing. >> # 2 patches left to apply: >> # b170635... my_commit_message >> # b170635... my_commit_message >> # (use "git commit --amend" to amend the current commit) >> # (use "git rebase --continue" once you are satisfied with your >> changes) >> # ...... >> # ...... >> >> What do you guys think ? > > I agree. When you're in the process of rebasing a big list of > commits, > it would produce a lot of not-so-useful output, when what you want to > see is, most of the time, which commit you are currently editing. > So, in my opinion, whole lists should not be displayed by default. > > Now, if I could suggest an improvement over that list: when you > rebase > some commits, I'm quite sure the history of what you already did is > stored somewhere since you can revert it which git rebase --abort. It > would be nice to improve that list by displaying these informations, > like: > > $ git status --rebase-state > # HEAD detached from ecb9f3e > # Already applied 4 patches: > # b170635... my_commit_message > # b170635... my_commit_message > # new: b170635... my_commit_message > # modified: b170635... my_commit_message > # reworded: b170635... my_commit_message > # You are currently editing a832578... my_commit_message [5/8] while > rebasing. > # 2 patches left to apply: > # b170635... my_commit_message > # b170635... my_commit_message > # (use "git commit --amend" to amend the current commit) > # (use "git rebase --continue" once you are satisfied with your > changes) > # ...... > # ...... > > I have no idea how complicated it would be to do that, though. > What do you think? If i'm not mistaking, it shouldn't be too hard, since it's pretty close to the content of .git/rebase-merge/done: reword a832578 rm: better error message on failure for multiple files edit fd0330b rm: introduce advice.rmHints to shorten messages -- Mathieu Liénard--Mayor, 2nd year at Grenoble INP - ENSIMAG (+33)6 80 56 30 02 ``` ## Antoine Pelisse, 2013-06-12 12:28 Subject: Re: New feature discussion: git rebase --status Message-ID: URL: https://gitlist.dev/e/CALWbr2xhhUNTo54u7K5iFr%2BwSMSiX6JrgTX%3DQJsDQ6E30uwDzQ%40mail.gmail.com In-Reply-To: <3cafe99fe3b868e6fc025110d324b9c8@ensibm.imag.fr> ``` On Wed, Jun 12, 2013 at 1:23 PM, Mathieu Liénard--Mayor wrote: > Le 2013-06-12 13:12, Célestin Matte a écrit : > >> Le 12/06/2013 12:17, Mathieu Liénard--Mayor a écrit : >>> >>> Now, I'm not sure if we should always display the list of commits >>> already applied and those left to apply. What I mean is that maybe it >>> would be better to make status require a flag to display the two lists. >>> Something like (not sure about the flag's name): >>> >>> $ git status --rebase-state >>> # HEAD detached from ecb9f3e >>> # Already applied 2 patches: >>> # b170635... my_commit_message >>> # b170635... my_commit_message >>> # You are currently editing a832578... my_commit_message [3/5] while >>> rebasing. >>> # 2 patches left to apply: >>> # b170635... my_commit_message >>> # b170635... my_commit_message >>> # (use "git commit --amend" to amend the current commit) >>> # (use "git rebase --continue" once you are satisfied with your >>> changes) >>> # ...... >>> # ...... >>> >>> What do you guys think ? >> >> >> I agree. When you're in the process of rebasing a big list of commits, >> it would produce a lot of not-so-useful output, when what you want to >> see is, most of the time, which commit you are currently editing. >> So, in my opinion, whole lists should not be displayed by default. Maybe we can display previous and next commits to provide some context. Like we do for diff. For example: $ git status # HEAD detached from ecb9f3e # Already applied 330 patches (displaying next 3): # b170635... my_commit_message # b170635... my_commit_message # b170635... my_commit_message # Already applied 119 (displaying last 3) # b170635... my_commit_message # b170635... my_commit_message # b170635... my_commit_message # You are currently editing a832578... my_commit_message [120/450] while rebasing. Also, I'm not sure about the "--rebase-state" flag. We should probably have some option to disable it (and re-enable if the default is changed through a config variable), but my understanding from previous messages was that not having to learn a new option to use that was quite important. As a consequence, I removed it from my example. ``` ## Matthieu Moy, 2013-06-12 12:41 Subject: Re: New feature discussion: git rebase --status Message-ID: URL: https://gitlist.dev/e/vpqehc7y00a.fsf%40anie.imag.fr In-Reply-To: ``` Mathieu Liénard--Mayor writes: > $ git status > # HEAD detached from ecb9f3e > # You are currently editing a832578... my_commit_message [3/5] while > rebasing. Showing the commit message here is too much IMHO. With a typical 50-characters message, it already gives # You are currently editing a832578 __________________________________________________ [3/5] while rebasing and we usually try to fit everything on a 80-columns terminal. My vote would go for just showing the short sha1. The user can run "git show $sha1" to get more information if needed, it's just a copy-paste away. If we want to show the commit message, it should be on its own line. -- Matthieu Moy http://www-verimag.imag.fr/~moy/ ``` ## Mathieu Liénard--Mayor, 2013-06-12 12:50 Subject: Re: New feature discussion: git rebase --status Message-ID: <7a0e5a6d3251dff96d4cc8b3ffb9957e@ensibm.imag.fr> URL: https://gitlist.dev/e/7a0e5a6d3251dff96d4cc8b3ffb9957e%40ensibm.imag.fr In-Reply-To: ``` Le 2013-06-12 14:44, shawn wilson a écrit : > Either leave it or just show the next, last, and current commit. Not > a whole --continue, --amend, etc stuff. The first time I had to > rebase > (about a month ago) it took me a minute to Google and figure the rest > out. Well, the current output looks like: $ git status # HEAD detached from ecb9f3e # You are currently editing a commit while rebasing. # (use "git commit --amend" to amend the current commit) # (use "git rebase --continue" once you are satisfied with your changes) # ..... so I don't think removing those pieces of advice would be a good idea, especially since you can deactivate it with advice.statusHints. > On Jun 12, 2013 8:29 AM, "Antoine Pelisse" > wrote: > >> On Wed, Jun 12, 2013 at 1:23 PM, Mathieu Liénard--Mayor >> wrote: >> > Le 2013-06-12 13:12, Célestin Matte a écrit : >> > >> >> Le 12/06/2013 12:17, Mathieu Liénard--Mayor a écrit : >> >>> >> >>> Now, I'm not sure if we should always display the list of >> commits >> >>> already applied and those left to apply. What I mean is that >> maybe it >> >>> would be better to make status require a flag to display the two >> lists. >> >>> Something like (not sure about the flag's name): >> >>> >> >>> $ git status --rebase-state >> >>> # HEAD detached from ecb9f3e >> >>> # Already applied 2 patches: >> >>> #     b170635... my_commit_message >> >>> #     b170635... my_commit_message >> >>> # You are currently editing a832578... my_commit_message [3/5] >> while >> >>> rebasing. >> >>> # 2 patches left to apply: >> >>> #    b170635... my_commit_message >> >>> #    b170635... my_commit_message >> >>> #   (use "git commit --amend" to amend the current commit) >> >>> #   (use "git rebase --continue" once you are satisfied with >> your >> >>> changes) >> >>> # ...... >> >>> # ...... >> >>> >> >>> What do you guys think ? >> >> >> >> >> >> I agree. When you're in the process of rebasing a big list of >> commits, >> >> it would produce a lot of not-so-useful output, when what you >> want to >> >> see is, most of the time, which commit you are currently editing. >> >> So, in my opinion, whole lists should not be displayed by >> default. >> >> Maybe we can display previous and next commits to provide some >> context. Like we do for diff. >> For example: >> >> $ git status >> # HEAD detached from ecb9f3e >> # Already applied 330 patches (displaying next 3): >> #     b170635... my_commit_message >> #     b170635... my_commit_message >> #     b170635... my_commit_message >> # Already applied 119 (displaying last 3) >> #     b170635... my_commit_message >> #     b170635... my_commit_message >> #     b170635... my_commit_message >> # You are currently editing a832578... my_commit_message [120/450] >> while rebasing. >> >> Also, I'm not sure about the "--rebase-state" flag. We should >> probably >> have some option to disable it (and re-enable if the default is >> changed through a config variable), but my understanding from >> previous >> messages was that not having to learn a new option to use that was >> quite important. As a consequence, I removed it from my example. >> -- >> To unsubscribe from this list: send the line "unsubscribe git" in >> the body of a message to majordomo@vger.kernel.org >> More majordomo info at  http://vger.kernel.org/majordomo-info.html >> [1] > > > Links: > ------ > [1] http://vger.kernel.org/majordomo-info.html -- Mathieu Liénard--Mayor, 2nd year at Grenoble INP - ENSIMAG (+33)6 80 56 30 02 ``` ## John Keeping, 2013-06-12 12:52 Subject: Re: New feature discussion: git rebase --status Message-ID: <20130612125226.GP22905@serenity.lan> URL: https://gitlist.dev/e/20130612125226.GP22905%40serenity.lan In-Reply-To: ``` On Wed, Jun 12, 2013 at 02:41:25PM +0200, Matthieu Moy wrote: > Mathieu Liénard--Mayor writes: > > > $ git status > > # HEAD detached from ecb9f3e > > # You are currently editing a832578... my_commit_message [3/5] while > > rebasing. > > Showing the commit message here is too much IMHO. With a typical > 50-characters message, it already gives > > # You are currently editing a832578 __________________________________________________ [3/5] while rebasing > > and we usually try to fit everything on a 80-columns terminal. > > My vote would go for just showing the short sha1. The user can run "git > show $sha1" to get more information if needed, it's just a copy-paste > away. If we want to show the commit message, it should be on its own > line. I agree. I liked your earlier suggestion of adding something like "(applying 1d3fb08, 2/5)". Where "applying" should be "cherry picking" or "reverting" when appropriate. I actually think this should be the only change to the default status output, additional information on the full list of commits being applied should either come from "git rebase --status" or some new flag to "git status" which is off by default. ``` ## Junio C Hamano, 2013-06-12 22:19 Subject: Re: New feature discussion: git rebase --status Message-ID: <7vzjuvynt0.fsf@alter.siamese.dyndns.org> URL: https://gitlist.dev/e/7vzjuvynt0.fsf%40alter.siamese.dyndns.org In-Reply-To: ``` Antoine Pelisse writes: > Maybe we can display previous and next commits to provide some > context. Like we do for diff. > For example: > > $ git status > # HEAD detached from ecb9f3e > # Already applied 330 patches (displaying next 3): > # b170635... my_commit_message > # b170635... my_commit_message > # b170635... my_commit_message > # Already applied 119 (displaying last 3) > # b170635... my_commit_message > # b170635... my_commit_message > # b170635... my_commit_message I think you meant one of them to be # Still to be applied 119 (showing the first 3) instead. I am not sure if it is worth 8 lines, especially given that "git log --oneline -$n" would give you "Already applied" part that is beyond what will be shown in this message easily if you wanted to. So it might be enough to show "The one that has last been replayed" (aka "HEAD") and "The one you are in the middle of replaying". ``` ## Antoine Pelisse, 2013-06-13 05:52 Subject: Re: New feature discussion: git rebase --status Message-ID: URL: https://gitlist.dev/e/CALWbr2x-4_QSurvScYL%2B2Utn%3D-K3Knb7Kif9SAvV_V-ZdvPfCw%40mail.gmail.com In-Reply-To: <7vzjuvynt0.fsf@alter.siamese.dyndns.org> ``` On Thu, Jun 13, 2013 at 12:19 AM, Junio C Hamano wrote: > Antoine Pelisse writes: > >> Maybe we can display previous and next commits to provide some >> context. Like we do for diff. >> For example: >> >> $ git status >> # HEAD detached from ecb9f3e >> # Already applied 330 patches (displaying next 3): >> # b170635... my_commit_message >> # b170635... my_commit_message >> # b170635... my_commit_message >> # Already applied 119 (displaying last 3) >> # b170635... my_commit_message >> # b170635... my_commit_message >> # b170635... my_commit_message > > I think you meant one of them to be > > # Still to be applied 119 (showing the first 3) > > instead. Of course, > I am not sure if it is worth 8 lines, especially given > that "git log --oneline -$n" would give you "Already applied" part > that is beyond what will be shown in this message easily if you > wanted to. So it might be enough to show "The one that has last > been replayed" (aka "HEAD") and "The one you are in the middle of > replaying". That's very true. The piece of information that is hard to get is "what's left to be done". So something like this would make sense: $ git status # HEAD detached from ecb9f3e # You are currently editing a832578... my_commit_message [120/450] while rebasing. # 320 patches left to apply (showing next 3): # b170635... my_commit_message # b170635... my_commit_message # b170635... my_commit_message # (use "git commit --amend" to amend the current commit) # (use "git rebase --continue" once you are satisfied with your changes) So that's 4 extra lines compared to current output. But should we make it a default ? ``` ## Mathieu Liénard--Mayor, 2013-06-13 12:19 Subject: Re: New feature discussion: git rebase --status Message-ID: URL: https://gitlist.dev/e/dc115f90be3bc5830473a6648bf37df5%40ensibm.imag.fr In-Reply-To: ``` Le 2013-06-13 07:52, Antoine Pelisse a écrit : > On Thu, Jun 13, 2013 at 12:19 AM, Junio C Hamano > wrote: >> Antoine Pelisse writes: >> >>> Maybe we can display previous and next commits to provide some >>> context. Like we do for diff. >>> For example: >>> >>> $ git status >>> # HEAD detached from ecb9f3e >>> # Already applied 330 patches (displaying next 3): >>> # b170635... my_commit_message >>> # b170635... my_commit_message >>> # b170635... my_commit_message >>> # Already applied 119 (displaying last 3) >>> # b170635... my_commit_message >>> # b170635... my_commit_message >>> # b170635... my_commit_message >> >> I think you meant one of them to be >> >> # Still to be applied 119 (showing the first 3) >> >> instead. > > Of course, > >> I am not sure if it is worth 8 lines, especially given >> that "git log --oneline -$n" would give you "Already applied" part >> that is beyond what will be shown in this message easily if you >> wanted to. So it might be enough to show "The one that has last >> been replayed" (aka "HEAD") and "The one you are in the middle of >> replaying". > > That's very true. The piece of information that is hard to get is > "what's left to be done". > > So something like this would make sense: > > $ git status > # HEAD detached from ecb9f3e > # You are currently editing a832578... my_commit_message [120/450] > while rebasing. > # 320 patches left to apply (showing next 3): > # b170635... my_commit_message > # b170635... my_commit_message > # b170635... my_commit_message > # (use "git commit --amend" to amend the current commit) > # (use "git rebase --continue" once you are satisfied with your > changes) > > So that's 4 extra lines compared to current output. But should we > make > it a default ? Personally I believe we should not make it the default output. Currently, the output I'm working on is the following: $ git status # HEAD detached from ecb9f3e # You are currently editing a832578 while rebasing branch 'split-rm-v7' on 'ecb9f3e'. # (use "git commit --amend" to amend the current commit) # (use "git rebase --continue" once you are satisfied with your changes) $ git status --rebase-todo # HEAD detached from ecb9f3e # You are currently editing a832578 while rebasing branch 'split-rm-v7' on 'ecb9f3e'. # Still 2 patches left to apply: # e a832578 rm: better error message on failure for multiple files # e fd0330b rm: introduce advice.rmHints to shorten messages # (use "git commit --amend" to amend the current commit) # (use "git rebase --continue" once you are satisfied with your changes) I'm still unsure about the name of the flag, I chose that one accordingly to .git/merge-rebase/rebase-todo -- Mathieu Liénard--Mayor, 2nd year at Grenoble INP - ENSIMAG (+33)6 80 56 30 02 ```