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

From: Julian Phillips <julian@quantumfyre.co.uk>
Date: Oct 17, 2009, 17:35 UTC
Message-ID: <alpine.LNX.2.00.0910171829430.7906@reaper.quantumfyre.co.uk>
In-Reply-To: <20091017170421.GA10490@atjola.homenet>

On Sat, 17 Oct 2009, Bj?rn Steinbrink wrote:

Show 45 quoted lines

> On 2009.10.17 16:15:13 +0100, Julian Phillips wrote:
>> On Fri, 16 Oct 2009, Nicolas Pitre wrote:
>>
>>> On Fri, 16 Oct 2009, Julian Phillips wrote:
>>>
>>>> My interest in this thread is solely that it might provide a mechanism to find
>>>> out which tag was checked out.  So, I'm just chucking in my $0.02 as a user.
>>>
>>> Try this:
>>>
>>> $ git checkout v1.5.5
>>> Note: moving to 'v1.5.5' which isn't a local branch
>>> If you want to create a new branch from this checkout, you may do so
>>> (now or later) by using -b with the checkout command again. Example:
>>> git checkout -b <new_branch_name>
>>> HEAD is now at 1d2375d... GIT 1.5.5
>>>
>>> [look around, and then ...]
>>>
>>> $ git checkout HEAD~2
>>> Previous HEAD position was 1d2375d... GIT 1.5.5
>>> HEAD is now at f61cc48... git-svn: fix following renamed paths when tracking a single path
>>>
>>> [go out for lunch ... and forget what this was about.]
>>>
>>> $ git reflog -3
>>> f61cc48 HEAD@{0}: checkout: moving from 1d2375d... to HEAD~2
>>> 1d2375d HEAD@{1}: checkout: moving from master to v1.5.5
>>> c274db7 HEAD@{2}: pull : Fast forward
>>>
>>> Here I have all the information to see what I did, and from what state.
>>> I even know that I did a pull on the master branch before moving away
>>> from it.  The -3 limits the log to 3 entries.  With no limit you get it
>>> all in your default pager.
>>>
>>> So there is no need for another mechanism to find out what tag was
>>> actually checked out -- you have it all already.
>>
>> What I want is a way for my build process to reliably know what
>> branch or tag is currently being built.  "git symbolic-ref HEAD"
>> will give me the branch name, but doesn't work for tags.  "git
>> describe" will find _a_ tag, but I can't tell if it's actually the
>> one checked out.
>
> Do you have multiple (annotated) tags for the same commit?

Potentially, yes. Releasing isn't the only thing that requires keeping track of things. It's even possible that the person creating the newer tag doesn't yet know that a release tag has been applied if the person who applied it hasn't yet pushed it back.

> Otherwise, I don't see why "git describe HEAD" should print the wrong 
> one. If there's a tag that can be resolved to the same commit that HEAD 
> can be resolved, then "git describe HEAD" must output that one. 
> Otherwise, that'd be a clear bug to me.

Oh, definately no bug. git describe works exactly as expected, the problem is that the tag checked out isn't always the latest tag applied to that commit.

-- 
Julian

  ---
Jayne: Shee-nio high tech Alliance crap!"
 				--Episode #9, "Ariel"