Re: [PATCH] status: display the SHA1 of the commit being currently processed

Le 2013-06-17 20:37, Junio C Hamano a écrit :

Mathieu Lienard--Mayor [off-list ref]
writes:

quoted

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 
was
too vague (ie. saying "...ing a commit") we replaced "a commit" by the 
SHA1.

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 
output

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 
stopped.
Display the list of what's left to be done isn't the purpose of this 
particular patch.

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

Will do.

'rebase' finishes" topic cf.

  
http://thread.gmane.org/gmane.comp.version-control.git/227994/focus=228092

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.

We have several modifications to make, so in the end we'll rebase on 
top of it.

In the longer term to address issues discussed in this thread cf.

  
http://thread.gmane.org/gmane.comp.version-control.git/227432/focus=227471

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.

Thanks.

-- 
Mathieu Liénard--Mayor,
2nd year at Grenoble INP - ENSIMAG
(+33)6 80 56 30 02