Re: git push tags

["Philip Oakley" <philipoakley@iee.org>]

From: "Chris Rorvick" <chris@rorvick.com> Sent: Sunday, October 28, 2012 
7:59 PM
> On Sun, Oct 28, 2012 at 1:15 PM, Johannes Sixt <j6t@kdbg.org> 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

>