From: "Chris Rorvick" <> Sent: Sunday, October 28, 2012 7:59 PM
On Sun, Oct 28, 2012 at 1:15 PM, Johannes Sixt <> wrote:
Tags are refs, just like branches. "Tags don't move" is just a
convention, and git doesn't even respect it (except possibly in one
place[1]). You can't reseat tags unless you use -f, which is exactly the
same with branches, which you can't reseat unless you use -f.

[1] By default, git fetch does not fetch tags that it already has.

Also, git checkout <tag> puts you on a detached HEAD.  This seems
pretty significant with regard to Git respecting a "tags don't move"

Surely the convention is the other way around. That is, it is branches that are _expected_ to move, hence unless you are checkout a branch (movable) you will be on a detached head at a fixed place/sha1 [aka not on a branch].

The checking out of a tag action doesn't make it more or less significant.

I think Angelo's original post should be reviewed to see if the issue can now be restated in a manner that shows up the implied conflict.

If I read it right it was where two users can tag two different commits with the same tag name [e.g. 'Release_V3.3'] and the last person to push wins, so anyone in the team can change what is to be the released version!


To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to
More majordomo info at

Reply via email to