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

[Junio C Hamano <gitster@pobox.com>]

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?

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?

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.
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.

Also, please pay closer attention to topics that are under
discussion in other threads.  I think Ram's "Fix 'checkout -' after
'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.

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.