On Thu, Apr 26, 2012 at 12:24 PM, Junio C Hamano <gitster@xxxxxxxxx> wrote: > Nathan Gray <n8gray@xxxxxxxxxx> writes: > >> So why is it that tag refs don't follow this model? > > Because the assumed development model for "people work inside their > private world (i.e. "branch"), but integration happens in common > namespace (i.e. somebody eventually pushes to "master branch" of the > repository that every project participant considers authoritative) and > the end product of the project is tagged there for everybody's > consumption. When something is called "version 1.0", it only invites > confusion if _my_ Git version 1.0 is different from _your_ Git version > 1.0, and it makes no sense for tags used in this manner not to be in a > global single namespace. People need to qualify such "version 1.0" as > "Junio's version 1.0" vs "Nathan's version 1.0" if they want to avoid > confusion anyway, and at that point you would not be talking about > refs/tags/v1.0, but refs/tags/jc/v1.0 vs refs/tags/ng/v1.0 or something. I see your point, but the assumption that there is some global tagging authority is quite surprising to me, considering the distributed nature of git. And honestly, I don't think it would be so confusing. Imagine: [~/src/git]$ git tag my-tag my-other-tag [~/src/git]$ git tag -a my-tag my-other-tag remotes/joeShmoe/v1.0 remotes/junio/v1.0 I think people would know which v1.0 to trust, in the same way that they know which is the authoritative branch when dealing with multiple remotes. I actually think this model is less confusing, in the sense that it helps unify the concept of "remote". There's this thing called a remote that represents the last-known state of a remote repository. That state includes branches, tags, etc. You can choose to incorporate that state into your own or ignore it, but it fundamentally belongs to the other repo and you can't change it except by pushing. Right now that's the way that branches work, but tags have their own rules for you to learn. > Other workflows that use private tags are possible and they might > benefit from having separate namespaces; it is just that they are not > the workflow Git was originally designed to support. That makes sense. Cheers, -n8 -- HexaLex: A New Angle on Crossword Games for iPhone and iPod Touch http://hexalex.com On The App Store: http://bit.ly/8Mj1CU On Facebook: http://bit.ly/9MIJiV On Twitter: http://twitter.com/hexalexgame http://n8gray.org -- 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