Re: New feature discussion: git rebase --status

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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@xxxxxxxxx> wrote:

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 [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 majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html




[Index of Archives]     [Linux Kernel Development]     [Gcc Help]     [IETF Annouce]     [DCCP]     [Netdev]     [Networking]     [Security]     [V4L]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux SCSI]     [Fedora Users]