New feature discussion: git rebase --status

New feature discussion: git rebase --status

[Mathieu Liénard--Mayor]

(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

Re: New feature discussion: git rebase --status

[Thomas Rast]

Mathieu Liénard--Mayor <mathieu.lienard--mayor@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

Re: New feature discussion: git rebase --status

[John Keeping]

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.

Re: New feature discussion: git rebase --status

[Matthieu Moy]

John Keeping <john@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/

Re: New feature discussion: git rebase --status

[Hilco Wijbenga]

On 11 June 2013 06:19, Matthieu Moy <Matthieu.Moy@grenoble-inp.fr> wrote:
> John Keeping <john@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.

Re: New feature discussion: git rebase --status

[Linus Torvalds]

On Tue, Jun 11, 2013 at 10:18 AM, Hilco Wijbenga
<hilco.wijbenga@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

Re: New feature discussion: git rebase --status

[Mathieu Liénard--Mayor]

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

Re: New feature discussion: git rebase --status

[Célestin Matte]

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

Re: New feature discussion: git rebase --status

[Mathieu Liénard--Mayor]

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

Re: New feature discussion: git rebase --status

[Antoine Pelisse]

On Wed, Jun 12, 2013 at 1:23 PM, Mathieu Liénard--Mayor
<mathieu.lienard--mayor@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.

Re: New feature discussion: git rebase --status

[Mathieu Liénard--Mayor]

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" <apelisse@gmail.com> 
> wrote:
>
>> On Wed, Jun 12, 2013 at 1:23 PM, Mathieu Liénard--Mayor
>> <mathieu.lienard--mayor@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 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

Re: New feature discussion: git rebase --status

[Junio C Hamano]

Antoine Pelisse <apelisse@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".

Re: New feature discussion: git rebase --status

[Antoine Pelisse]

On Thu, Jun 13, 2013 at 12:19 AM, Junio C Hamano <gitster@pobox.com> wrote:
> Antoine Pelisse <apelisse@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 ?

Re: New feature discussion: git rebase --status

[Mathieu Liénard--Mayor]

Le 2013-06-13 07:52, Antoine Pelisse a écrit :
> On Thu, Jun 13, 2013 at 12:19 AM, Junio C Hamano <gitster@pobox.com> 
> wrote:
>> Antoine Pelisse <apelisse@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

Re: New feature discussion: git rebase --status

[Matthieu Moy]

Mathieu Liénard--Mayor <mathieu.lienard--mayor@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/

Re: New feature discussion: git rebase --status

[John Keeping]

On Wed, Jun 12, 2013 at 02:41:25PM +0200, Matthieu Moy wrote:
> Mathieu Liénard--Mayor <mathieu.lienard--mayor@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.

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.