Re: git push tags

From: Philip Oakley <philipoakley@iee.org>
Date: Oct 28, 2012, 21:37 UTC
Message-ID: <4B8097A9D6854CDFA27E7CF6574B37BA@PhilipOakley>
In-Reply-To: <CAEUsAPYREy=CvPxy_Mzh5icVQo3=NV-AMC096Op0WWODLPH47Q@mail.gmail.com>

From: "Chris Rorvick" <chris@rorvick.com> Sent: Sunday, October 28, 2012 
7:59 PM

Show 12 quoted lines

> 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