Re: [PATCH] Proof-of-concept patch to remember what the detached HEAD was

From: Julian Phillips <julian@quantumfyre.co.uk>
Date: Oct 17, 2009, 15:32 UTC
Message-ID: <alpine.LNX.2.00.0910171617580.6644@reaper.quantumfyre.co.uk>
In-Reply-To: <7vk4yvt7kp.fsf@alter.siamese.dyndns.org>

On Fri, 16 Oct 2009, Junio C Hamano wrote:

Show 42 quoted lines

> Julian Phillips <julian@quantumfyre.co.uk> writes:
>
>> On Fri, 16 Oct 2009, Junio C Hamano wrote:
>>
>>> Julian Phillips <julian@quantumfyre.co.uk> 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 ...

Show 7 quoted lines

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