Re: New feature discussion: git rebase --status
Le 2013-06-13 07:52, Antoine Pelisse a écrit : On Thu, Jun 13, 2013 at 12:19 AM, Junio C Hamano gits...@pobox.com wrote: Antoine Pelisse apeli...@gmail.com 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 -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: New feature discussion: git rebase --status
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 -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: New feature discussion: git rebase --status
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 -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: New feature discussion: git rebase --status
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 -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: New feature discussion: git rebase --status
On Wed, Jun 12, 2013 at 1:23 PM, Mathieu Liénard--Mayor mathieu.lienard--ma...@ensimag.fr 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 majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: New feature discussion: git rebase --status
Mathieu Liénard--Mayor mathieu.lienard--ma...@ensimag.fr 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/ -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: New feature discussion: git rebase --status
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 apeli...@gmail.com wrote: On Wed, Jun 12, 2013 at 1:23 PM, Mathieu Liénard--Mayor mathieu.lienard--ma...@ensimag.fr 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 majord...@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 -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: New feature discussion: git rebase --status
Antoine Pelisse apeli...@gmail.com 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. -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: New feature discussion: git rebase --status
On Thu, Jun 13, 2013 at 12:19 AM, Junio C Hamano gits...@pobox.com wrote: Antoine Pelisse apeli...@gmail.com 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 ? -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
New feature discussion: git rebase --status
(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 -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: New feature discussion: git rebase --status
Mathieu Liénard--Mayor mathieu.lienard--ma...@ensimag.fr 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
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: New feature discussion: git rebase --status
John Keeping j...@keeping.me.uk 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/ -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: New feature discussion: git rebase --status
On 11 June 2013 06:19, Matthieu Moy matthieu@grenoble-inp.fr wrote: John Keeping j...@keeping.me.uk 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. -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: New feature discussion: git rebase --status
On Tue, Jun 11, 2013 at 10:18 AM, Hilco Wijbenga hilco.wijbe...@gmail.com 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 -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
