On Sat, 17 Oct 2009, Bj?rn Steinbrink wrote:
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"
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html