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/
On 11 June 2013 06:19, Matthieu Moy [off-list ref] wrote:
John Keeping [off-list ref] writes:
quoted
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)"
quoted
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.
On Tue, Jun 11, 2013 at 10:18 AM, Hilco Wijbenga
[off-list ref] 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
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
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
Le 12/06/2013 12:17, Mathieu Liénard--Mayor a écrit :
quoted
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
From: Antoine Pelisse <hidden> Date: 2016-06-15 22:57:42
On Wed, Jun 12, 2013 at 1:23 PM, Mathieu Liénard--Mayor
[off-list ref] wrote:
Le 2013-06-12 13:12, Célestin Matte a écrit :
quoted
Le 12/06/2013 12:17, Mathieu Liénard--Mayor a écrit :
quoted
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.