{"thread":{"id":"30340","subject":"Why aren't tag refs namespaced?","startedAt":"2012-04-26T18:40:54Z","lastAt":"2012-04-27T03:26:23Z","messageCount":7,"participants":["Nathan Gray","Junio C Hamano","Marc Branchaud"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"190132","messageId":"CA+7g9Jxc6eaCUR8aVhqKH--sOrvQVrZn+se7wtFJsOiKNjz9Pg@mail.gmail.com","threadId":"30340","inReplyTo":null,"subject":"Why aren't tag refs namespaced?","fromName":"Nathan Gray","fromEmail":"n8gray@n8gray.org","sentAt":"2012-04-26T18:40:54Z","receivedAt":"2012-04-26T18:40:54Z","isPatch":false,"sender":{"key":"n8gray@n8gray.org","avatar":"https://avatars.githubusercontent.com/u/82794?v=4"},"body":"Hey guys,\n\nNamespacing works really well for branch refs. I know that\nremotes/origin/master is origin's master branch. I may or may not\nhave a master branch, and it may or may not have anything in common\nwith origin's. Our repositories are independent, after all, so it\nmakes sense that our refs would live in different namespaces.\n\nSo why is it that tag refs don't follow this model? Why is my\n\"best-commit-ever\" tag assumed to be the same as origin's? Given a\nref in refs/tags it's unclear if the ref is public, private, on origin\nor not on origin. Will pushing my tags create anything new or not?\nWho knows? Compare this to branches, where the same questions are\neasy to answer thanks to namespacing.\n\nOTOH, am I just not \"getting it?\" I've been using git for about 4\nyears now and I feel like I know it pretty well but it's possible I'm\njust misunderstanding things.\n\nBTW, I just read the \"On Automatic following\" section of the git tag\nman page and I found it very confusing. It seems to be justifying a\nbehavior without first describing what the behavior is.\n\nThanks,\n-Nathan\n\n-- \nHexaLex: A New Angle on Crossword Games for iPhone and iPod Touch\nhttp://hexalex.com\nOn The App Store: http://bit.ly/8Mj1CU\nOn Facebook: http://bit.ly/9MIJiV\nOn Twitter: http://twitter.com/hexalexgame\nhttp://n8gray.org\n"},{"id":"190137","messageId":"xmqqty068ffd.fsf@junio.mtv.corp.google.com","threadId":"30340","inReplyTo":"CA+7g9Jxc6eaCUR8aVhqKH--sOrvQVrZn+se7wtFJsOiKNjz9Pg@mail.gmail.com","subject":"Re: Why aren't tag refs namespaced?","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2012-04-26T19:24:22Z","receivedAt":"2012-04-26T19:24:22Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Nathan Gray writes:\n\n> So why is it that tag refs don't follow this model?\n\nBecause the assumed development model for \"people work inside their\nprivate world (i.e. \"branch\"), but integration happens in common\nnamespace (i.e. somebody eventually pushes to \"master branch\" of the\nrepository that every project participant considers authoritative) and\nthe end product of the project is tagged there for everybody's\nconsumption. When something is called \"version 1.0\", it only invites\nconfusion if _my_ Git version 1.0 is different from _your_ Git version\n1.0, and it makes no sense for tags used in this manner not to be in a\nglobal single namespace. People need to qualify such \"version 1.0\" as\n\"Junio's version 1.0\" vs \"Nathan's version 1.0\" if they want to avoid\nconfusion anyway, and at that point you would not be talking about\nrefs/tags/v1.0, but refs/tags/jc/v1.0 vs refs/tags/ng/v1.0 or something.\n\nOther workflows that use private tags are possible and they might\nbenefit from having separate namespaces; it is just that they are not\nthe workflow Git was originally designed to support.\n"},{"id":"190142","messageId":"4F99AACC.2050409@xiplink.com","threadId":"30340","inReplyTo":"CA+7g9Jxc6eaCUR8aVhqKH--sOrvQVrZn+se7wtFJsOiKNjz9Pg@mail.gmail.com","subject":"Re: Why aren't tag refs namespaced?","fromName":"Marc Branchaud","fromEmail":"marcnarc@xiplink.com","sentAt":"2012-04-26T20:06:36Z","receivedAt":"2012-04-26T20:06:36Z","isPatch":false,"sender":{"key":"marcnarc@xiplink.com","avatar":"https://avatars.githubusercontent.com/u/14980203?v=4"},"body":"On 12-04-26 02:40 PM, Nathan Gray wrote:\n> Hey guys,\n> \n> Namespacing works really well for branch refs. I know that\n> remotes/origin/master is origin's master branch. I may or may not\n> have a master branch, and it may or may not have anything in common\n> with origin's. Our repositories are independent, after all, so it\n> makes sense that our refs would live in different namespaces.\n> \n> So why is it that tag refs don't follow this model? Why is my\n> \"best-commit-ever\" tag assumed to be the same as origin's? Given a\n> ref in refs/tags it's unclear if the ref is public, private, on origin\n> or not on origin. Will pushing my tags create anything new or not?\n> Who knows? Compare this to branches, where the same questions are\n> easy to answer thanks to namespacing.\n\nThere was lengthy, but inconclusive, discussion about this a year ago:\n\nhttp://thread.gmane.org/gmane.comp.version-control.git/165799/focus=166290\n\n\t\tM.\n"},{"id":"190187","messageId":"CA+7g9JzpLkNHT_o1QyJ_r=4DrauWOPFr5XR_CPeAHGcLpLoD+w@mail.gmail.com","threadId":"30340","inReplyTo":"xmqqty068ffd.fsf@junio.mtv.corp.google.com","subject":"Re: Why aren't tag refs namespaced?","fromName":"Nathan Gray","fromEmail":"n8gray@n8gray.org","sentAt":"2012-04-26T23:33:07Z","receivedAt":"2012-04-26T23:33:07Z","isPatch":false,"sender":{"key":"n8gray@n8gray.org","avatar":"https://avatars.githubusercontent.com/u/82794?v=4"},"body":"On Thu, Apr 26, 2012 at 12:24 PM, Junio C Hamano wrote:\n> Nathan Gray writes:\n>\n>> So why is it that tag refs don't follow this model?\n>\n> Because the assumed development model for \"people work inside their\n> private world (i.e. \"branch\"), but integration happens in common\n> namespace (i.e. somebody eventually pushes to \"master branch\" of the\n> repository that every project participant considers authoritative) and\n> the end product of the project is tagged there for everybody's\n> consumption.  When something is called \"version 1.0\", it only invites\n> confusion if _my_ Git version 1.0 is different from _your_ Git version\n> 1.0, and it makes no sense for tags used in this manner not to be in a\n> global single namespace.  People need to qualify such \"version 1.0\" as\n> \"Junio's version 1.0\" vs \"Nathan's version 1.0\" if they want to avoid\n> confusion anyway, and at that point you would not be talking about\n> refs/tags/v1.0, but refs/tags/jc/v1.0 vs refs/tags/ng/v1.0 or something.\n\nI see your point, but the assumption that there is some global tagging\nauthority is quite surprising to me, considering the distributed\nnature of git. And honestly, I don't think it would be so confusing.\nImagine:\n\n[~/src/git]$ git tag\nmy-tag\nmy-other-tag\n\n[~/src/git]$ git tag -a\nmy-tag\nmy-other-tag\nremotes/joeShmoe/v1.0\nremotes/junio/v1.0\n\nI think people would know which v1.0 to trust, in the same way that\nthey know which is the authoritative branch when dealing with multiple\nremotes.\n\nI actually think this model is less confusing, in the sense that it\nhelps unify the concept of \"remote\". There's this thing called a\nremote that represents the last-known state of a remote repository.\nThat state includes branches, tags, etc. You can choose to\nincorporate that state into your own or ignore it, but it\nfundamentally belongs to the other repo and you can't change it except\nby pushing. Right now that's the way that branches work, but tags\nhave their own rules for you to learn.\n\n> Other workflows that use private tags are possible and they might\n> benefit from having separate namespaces; it is just that they are not\n> the workflow Git was originally designed to support.\n\nThat makes sense.\n\nCheers,\n-n8\n\n-- \nHexaLex: A New Angle on Crossword Games for iPhone and iPod Touch\nhttp://hexalex.com\nOn The App Store: http://bit.ly/8Mj1CU\nOn Facebook: http://bit.ly/9MIJiV\nOn Twitter: http://twitter.com/hexalexgame\nhttp://n8gray.org\n"},{"id":"190188","messageId":"CA+7g9JxpLs9rqRpacmLvnJ-2mZPCT+Bwd8J4-vp27HCZPTS0pA@mail.gmail.com","threadId":"30340","inReplyTo":"4F99AACC.2050409@xiplink.com","subject":"Re: Why aren't tag refs namespaced?","fromName":"Nathan Gray","fromEmail":"n8gray@n8gray.org","sentAt":"2012-04-26T23:34:04Z","receivedAt":"2012-04-26T23:34:04Z","isPatch":false,"sender":{"key":"n8gray@n8gray.org","avatar":"https://avatars.githubusercontent.com/u/82794?v=4"},"body":"On Thu, Apr 26, 2012 at 1:06 PM, Marc Branchaud wrote:\n>\n> There was lengthy, but inconclusive, discussion about this a year ago:\n>\n> http://thread.gmane.org/gmane.comp.version-control.git/165799/focus=166290\n\nThanks for the reference. I'll give that a read.\nCheers,\n-n8\n\n-- \nHexaLex: A New Angle on Crossword Games for iPhone and iPod Touch\nhttp://hexalex.com\nOn The App Store: http://bit.ly/8Mj1CU\nOn Facebook: http://bit.ly/9MIJiV\nOn Twitter: http://twitter.com/hexalexgame\nhttp://n8gray.org\n"},{"id":"190189","messageId":"CA+7g9Jy24VRO9Tr0o_4RNZN05fhyn5TZLo1C74CK+LbZduCJbw@mail.gmail.com","threadId":"30340","inReplyTo":"CABURp0okZ=-sq7e0ReUepCOEUC=9r2845wQ6H3HhruRg8Jd6Dg@mail.gmail.com","subject":"Re: Why aren't tag refs namespaced?","fromName":"Nathan Gray","fromEmail":"n8gray@n8gray.org","sentAt":"2012-04-26T23:48:33Z","receivedAt":"2012-04-26T23:48:33Z","isPatch":false,"sender":{"key":"n8gray@n8gray.org","avatar":"https://avatars.githubusercontent.com/u/82794?v=4"},"body":"CC'ing the list\n\nOn Thu, Apr 26, 2012 at 12:04 PM, Phil Hord wrote:\n> On Thu, Apr 26, 2012 at 2:40 PM, Nathan Gray wrote:\n>> Namespacing works really well for branch refs.  I know that\n>> remotes/origin/master is origin's master branch.  I may or may not\n>> have a master branch, and it may or may not have anything in common\n>> with origin's.  Our repositories are independent, after all, so it\n>> makes sense that our refs would live in different namespaces.\n>>\n>> So why is it that tag refs don't follow this model?\n>\n> I expect the simple answer is that no one has been motivated to create\n> such a mode.\n>\n>\n>> Why is my\n>> \"best-commit-ever\" tag assumed to be the same as origin's?  Given a\n>> ref in refs/tags it's unclear if the ref is public, private, on origin\n>> or not on origin.  Will pushing my tags create anything new or not?\n>> Who knows?  Compare this to branches, where the same questions are\n>> easy to answer thanks to namespacing.\n>>\n>> OTOH, am I just not \"getting it?\"  I've been using git for about 4\n>> years now and I feel like I know it pretty well but it's possible I'm\n>> just misunderstanding things.\n>\n>\n> Tags are presumed not to move, so there's no point in having a remote\n> tag which you follow with your local tag.  In that sense, they are\n> fundamentally different from branches.  Also, tags are not pushed by\n> default, though they are fetched if they're on branches you are\n> fetching.\n\nAll that is true, but...\n\n> On the other hand, it does invite namespace collisions if\n> you pull tags from a remote whilst having local tags and no\n> agreed-upon convention.\n\nExactly! Imagine tracking 5 different forks of the same project on\nGitHub. They can't be expected to coordinate their tagging\nconventions.\n\n> But perhaps a convention is what you need.  Suppose you name all your\n> local tags \"refs/tags/n8gray/best-commit-ever\"?  Or maybe you can 'git\n> fetch origin \"refs/tags/*:refs/tags/origin/*\"'.\n\nThat could probably be made to work, but it requires a fair bit of\neffort to keep clean. Plus you have to make sure you never\naccidentally use the built-in tag pushing/pulling stuff or it all\nfalls apart.\n\nCheers,\n-n8\n\n-- \nHexaLex: A New Angle on Crossword Games for iPhone and iPod Touch\nhttp://hexalex.com\nOn The App Store: http://bit.ly/8Mj1CU\nOn Facebook: http://bit.ly/9MIJiV\nOn Twitter: http://twitter.com/hexalexgame\nhttp://n8gray.org\n"},{"id":"190191","messageId":"xmqq62cl7t40.fsf@junio.mtv.corp.google.com","threadId":"30340","inReplyTo":"CA+7g9JzpLkNHT_o1QyJ_r=4DrauWOPFr5XR_CPeAHGcLpLoD+w@mail.gmail.com","subject":"Re: Why aren't tag refs namespaced?","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2012-04-27T03:26:23Z","receivedAt":"2012-04-27T03:26:23Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Nathan Gray writes:\n\n>> Other workflows that use private tags are possible and they might\n>> benefit from having separate namespaces; it is just that they are not\n>> the workflow Git was originally designed to support.\n>\n> That makes sense.\n\nYeah, as I said, the current behaviour aims to support a particular\nworkflow, e.g.\n\n * \"git fetch --tags\" uses a built-in refspec \"refs/tags/*:refs/tags/*\"\n and that maps a tag at the remote to the same location in the refs/\n hierarchy in the local repository.\n\n * \"git fetch\" that stores the history it fetches to local repository\n (i.e. uses refspec with non-empty RHS), when run without \"--no-tags\",\n fetches tags that point at commits in the fetched history from the\n remote and stores them at the same location in the refs/ hierarchy.\n\nand does it well.\n\nBut there is nothing in Git that fundamentally forces you to follow that\npattern. It is entirely plausible to enhance the former (i.e. --tags)\nto a bool-or-string option to let you specify different refs/ hierarchy\n(e.g. \"--tags\" would use \"refs/tags/*:refs/tags/*\" to map the names,\nwhile \"--tags=refs/remotes/origin/tags\" might store fetched tags in\nspecified place that is different from refs/tags/), and to add a new\noption to specify where the auto-followed tags would be stored to\nenhance the latter.\n"}]}