threads / discuss / 34101

New feature discussion: git rebase --status

Subject: New feature discussion: git rebase --status

## tl;dr

16 messages between Jun 11, 2013 and Jun 13, 2013.

replies: 15people: 9as markdown or json

Mathieu Liénard--Mayor· Jun 11, 2013, 12:35 UTC · lore

(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· Jun 11, 2013, 12:40 UTC · re: Mathieu Liénard--Mayor · lore

Re: New feature discussion: git rebase --status

Mathieu Liénard--Mayor <mathieu.lienard--mayor@ensimag.fr> writes:
Show 31 quoted lines
> (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· Jun 11, 2013, 12:55 UTC · re: Mathieu Liénard--Mayor · lore

Re: New feature discussion: git rebase --status

On Tue, Jun 11, 2013 at 02:35:29PM +0200, Mathieu Liénard--Mayor wrote:
Show 21 quoted lines
> (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· Jun 11, 2013, 13:19 UTC · re: John Keeping · lore

Re: New feature discussion: git rebase --status

John Keeping <john@keeping.me.uk> writes:
Show 5 quoted lines
> 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· Jun 11, 2013, 17:18 UTC · re: Matthieu Moy · lore

Re: New feature discussion: git rebase --status

On 11 June 2013 06:19, Matthieu Moy <Matthieu.Moy@grenoble-inp.fr> wrote:
Show 20 quoted lines
> 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.

Linus Torvalds· Jun 11, 2013, 17:23 UTC · re: Hilco Wijbenga · lore

Re: New feature discussion: git rebase --status

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
Mathieu Liénard--Mayor· Jun 12, 2013, 10:17 UTC · re: Linus Torvalds · lore

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
Célestin Matte· Jun 12, 2013, 11:12 UTC · re: Mathieu Liénard--Mayor · lore

Re: New feature discussion: git rebase --status

Le 12/06/2013 12:17, Mathieu Liénard--Mayor a écrit :
Show 21 quoted lines
> 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· Jun 12, 2013, 11:23 UTC · re: Célestin Matte · lore

Re: New feature discussion: git rebase --status

Le 2013-06-12 13:12, Célestin Matte a écrit :
Show 60 quoted lines
> 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· Jun 12, 2013, 12:28 UTC · re: Mathieu Liénard--Mayor · lore

Re: New feature discussion: git rebase --status

On Wed, Jun 12, 2013 at 1:23 PM, Mathieu Liénard--Mayor <mathieu.lienard--mayor@ensimag.fr> wrote:

Show 32 quoted lines
> 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.

Junio C Hamano· Jun 12, 2013, 22:19 UTC · re: Antoine Pelisse · lore

Re: New feature discussion: git rebase --status

Antoine Pelisse <apelisse@gmail.com> writes:
Show 14 quoted lines
> 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· Jun 13, 2013, 05:52 UTC · re: Junio C Hamano · lore

Re: New feature discussion: git rebase --status

On Thu, Jun 13, 2013 at 12:19 AM, Junio C Hamano <gitster@pobox.com> wrote:
Show 22 quoted lines
> 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,
Show 6 quoted lines
> 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· Jun 13, 2013, 12:19 UTC · re: Antoine Pelisse · lore

Re: New feature discussion: git rebase --status

Le 2013-06-13 07:52, Antoine Pelisse a écrit :
Show 54 quoted lines
> 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
Matthieu Moy· Jun 12, 2013, 12:41 UTC · re: Mathieu Liénard--Mayor · lore

Re: New feature discussion: git rebase --status

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/
John Keeping· Jun 12, 2013, 12:52 UTC · re: Matthieu Moy · lore

Re: New feature discussion: git rebase --status

On Wed, Jun 12, 2013 at 02:41:25PM +0200, Matthieu Moy wrote:
Show 18 quoted lines
> 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.

Mathieu Liénard--Mayor· Jun 12, 2013, 12:50 UTC · lore

Re: New feature discussion: git rebase --status

Le 2013-06-12 14:44, shawn wilson a écrit :
Show 5 quoted lines
> 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.

Show 80 quoted lines
> 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

← back to recent threads