On Sun, Oct 28, 2012 at 4:49 PM, Philip Oakley <philipoak...@iee.org> wrote: > From: "Chris Rorvick" <ch...@rorvick.com> Sent: Sunday, October 28, 2012 > 7:59 PM > >> On Sun, Oct 28, 2012 at 1:15 PM, Johannes Sixt <j...@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.
Ah, that makes sense. Thanks. So it sounds like the solution should be something more general than checking if the prefix is "refs/tags" if I understand your point correctly. Also, setting the status to REF_STATUS_REJECT_NONFASTFORWARD even when it would be a fast-forward (does that terminology apply to non-branch refs?) is confusing. It's already confusing that a failure to push a tag tells me I need to fetch and merge in the changes. Chris -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
