Mathieu Lienard--Mayor <Mathieu.Lienard--Mayor@xxxxxxxxxxxxxxx> 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. -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html