Le 2013-06-17 20:37, Junio C Hamano a écrit :
Mathieu Lienard--Mayor <mathieu.lienard--ma...@ensimag.imag.fr>
When in the middle of a rebase, it can be annoying to go in .git
in order to find the SHA1 of the commit where the rebase stopped.
git-status now includes this information in its default output.
With this new information, the message is now shorter, to avoid
too long lines.
The new message looks like:
$ git status
HEAD detached from 33e516f
Editing c346c87 while rebasing branch 'rebase_i_edit' on 'f90e540'.
Hmph. It only looks into rebase-merge and not rebase-apply; is this
patch complete, or just to show a Work-In-Progress?
It's a complete patch, at least we considered it as one.
We didn't want to change the output too much, so when the old message
too vague (ie. saying "...ing a commit") we replaced "a commit" by the
I do not think you need to introduce a new stopped-sha file (if you
need it, call that with "sha-1"). "git rebase [-i/-m]" knows where
it stopped and what the next step is without having to have such an
extra file. Why should you need one?
I'm not following. At what point are we introducing a new file ?
What we meant to do was:
- if the user removed the file .git/.../stopped_sha for some reason,
go back to the old "too vague" output
- otherwise, use the content of the file to display the SHA1 in the
It seems that wt_status_get_state() tries to read in-progress state
for various operations, and I think the logic to _detect_ what to
show (i.e. what is the next commit to be replayed? how many more
remains to be replayed?, etc.) would mix well with that function.
This patch is meant to be a first-step.
The only modification it's supposed to bring is the SHA1 where we
Display the list of what's left to be done isn't the purpose of this
Extend wt_status_state structure to hold the necessary info, query
the state from the filesystem in that function, and display the info
(but not collect info) in show_rebase_in_progress(), to keep the
clean division of labor between these two places.
Do you mean that we should include the stopped_SHA in wt_status_state ?
Also, please pay closer attention to topics that are under
discussion in other threads. I think Ram's "Fix 'checkout -' after
We have several modifications to make, so in the end we'll rebase on
top of it.
'rebase' finishes" topic cf.
makes the output reasonably better and consistent (please check what
I'll be pushing out on 'pu' later today after fixing some of them
up). I suspect that this patch will conflict with it, so either you
would need to wait, or work together with that branch (i.e. rebase
on top of it as necessary), or something.
In the longer term to address issues discussed in this thread cf.
I think the right direction is *NOT* to keep the first "HEAD
detached at" line and to add more cruft to the status output as
additional lines, when various sequencer-like operations that
tentatively take you to detached HEAD state to give control back to
you in the middle. "git status" knows what operation is in
progress, and I think we should start our output _without_ that
"HEAD detached at" line.
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 majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html