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

["Björn Steinbrink" <B.Steinbrink@gmx.de>]

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

Björn