From: Julian Phillips Date: Sat, 17 Oct 2009 15:32:14 GMT Subject: Re: [PATCH] Proof-of-concept patch to remember what the detached HEAD was Message-ID: In-Reply-To: <7vk4yvt7kp.fsf@alter.siamese.dyndns.org> On Fri, 16 Oct 2009, Junio C Hamano wrote: > Julian Phillips writes: > >> On Fri, 16 Oct 2009, Junio C Hamano wrote: >> >>> Julian Phillips writes: >>> ... >>>> I don't care what git has to do, I'm talking about the user experience >>> >>> But Bj?rn is showing two commands the _user_ has to type, iow, the comment >>> is about the user experience. >> >> Only Currently. My point was that _if_ we wanted to support this sort >> of thing, then we can make is simpler to do by providing a simple >> command for the user. >> >> The point I wanted to make was that the decision on what to do should >> be driven by the user's experience - not by the fact that it is easier >> to implement something else. > > Sorry, but I do not see in what way what you said in the thread connects > to the above three lines. Are you talking about this one from you a few > messages back? > > How about: > > $ git checkout origin/master > $ git fetch > Refusing to fetch, as it would update a checkedout branch > "git fetch -f" will force the update, but you will need to run "git > reset --hard HEAD" to update your checkout to match. > > I am not seeing "not the implementation ease but the user experience" > drive in this suggestion. If you are driving from the user experience > point of view, I would have instead suggested: > > How about: > > $ git checkout origin/master > $ git fetch > > and fetch happily updates the tracked branch, without affecting the > HEAD state (nor index nor the work tree, of course). True. I was saying that having git stop and explain things is better than making a mess for the user to clear up. Having it just work would of course be even better. Hoist by my own petard indead ... >> My interest in this thread is solely that it might provide a mechanism >> to find out which tag was checked out. > > Hmm, what is lacking in "git describe HEAD" for that? I am not > complaining that you might be asking for something that exists, but I _do_ > want to know if something that exists is not a satisfactory solution and > if so how it can be improved. What is lacking is the "checked out" part. "git describe HEAD" will tell me _a_ tag that matches the currently checked out state. However, it makes no guarantee that it was the one I checked out. If I tag the code with "v1.0.0", and a colleague later tags it with "this_version_sucks", then when I check out and build the code for the customer the version it reports could well be "this_version_sucks" instead of "v1.0.0" ... Nicolas Pitre suggested using the reflog, which does seem to include the information that I want, but I feel a little uneasy about accessing it via a script - how certain is it that the format of the message won't change? Is accessing the reflog the sort of thing people expect as part of the scripting interface? -- Julian --- Those who would repeat the past must control the teaching of history. -- Bene Gesserit Coda