From: "Chris Rorvick" <chris@xxxxxxxxxxx> Sent: Sunday, October 28, 2012
7:59 PM
On Sun, Oct 28, 2012 at 1:15 PM, Johannes Sixt <j6t@xxxxxxxx> 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"
convention.
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!
Philip
--
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