On Wed, Jun 12, 2013 at 1:23 PM, Mathieu Liénard--Mayor <mathieu.lienard--mayor@xxxxxxxxxx> 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@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html