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

["Mathieu Liénard--Mayor" <mathieu.lienard--mayor@ensimag.fr>]

Le 2013-06-17 20:37, Junio C Hamano a écrit :
> Mathieu Lienard--Mayor <Mathieu.Lienard--Mayor@ensimag.imag.fr>
> writes:
>
>> 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