From: Mathieu Liénard--Mayor Date: Tue, 18 Jun 2013 10:12:22 GMT Subject: Re: [PATCH] status: display the SHA1 of the commit being currently processed Message-ID: <2dc2004fbf61d625515c2b6f62cc104e@ensibm.imag.fr> In-Reply-To: <7vy5a8d1my.fsf@alter.siamese.dyndns.org> Le 2013-06-17 20:37, Junio C Hamano a écrit : > Mathieu Lienard--Mayor > 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