# Why aren't tag refs namespaced? 7 messages from 2012-04-26 to 2012-04-27. Participants: Nathan Gray, Junio C Hamano, Marc Branchaud. Thread: https://gitlist.dev/t/30340 ## Nathan Gray, 2012-04-26 18:40 Subject: Why aren't tag refs namespaced? Message-ID: URL: https://gitlist.dev/e/CA%2B7g9Jxc6eaCUR8aVhqKH--sOrvQVrZn%2Bse7wtFJsOiKNjz9Pg%40mail.gmail.com ``` Hey guys, Namespacing works really well for branch refs. I know that remotes/origin/master is origin's master branch. I may or may not have a master branch, and it may or may not have anything in common with origin's. Our repositories are independent, after all, so it makes sense that our refs would live in different namespaces. So why is it that tag refs don't follow this model? Why is my "best-commit-ever" tag assumed to be the same as origin's? Given a ref in refs/tags it's unclear if the ref is public, private, on origin or not on origin. Will pushing my tags create anything new or not? Who knows? Compare this to branches, where the same questions are easy to answer thanks to namespacing. OTOH, am I just not "getting it?" I've been using git for about 4 years now and I feel like I know it pretty well but it's possible I'm just misunderstanding things. BTW, I just read the "On Automatic following" section of the git tag man page and I found it very confusing. It seems to be justifying a behavior without first describing what the behavior is. Thanks, -Nathan -- 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 ``` ## Junio C Hamano, 2012-04-26 19:24 Subject: Re: Why aren't tag refs namespaced? Message-ID: URL: https://gitlist.dev/e/xmqqty068ffd.fsf%40junio.mtv.corp.google.com In-Reply-To: ``` Nathan Gray 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. 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. ``` ## Marc Branchaud, 2012-04-26 20:06 Subject: Re: Why aren't tag refs namespaced? Message-ID: <4F99AACC.2050409@xiplink.com> URL: https://gitlist.dev/e/4F99AACC.2050409%40xiplink.com In-Reply-To: ``` On 12-04-26 02:40 PM, Nathan Gray wrote: > Hey guys, > > Namespacing works really well for branch refs. I know that > remotes/origin/master is origin's master branch. I may or may not > have a master branch, and it may or may not have anything in common > with origin's. Our repositories are independent, after all, so it > makes sense that our refs would live in different namespaces. > > So why is it that tag refs don't follow this model? Why is my > "best-commit-ever" tag assumed to be the same as origin's? Given a > ref in refs/tags it's unclear if the ref is public, private, on origin > or not on origin. Will pushing my tags create anything new or not? > Who knows? Compare this to branches, where the same questions are > easy to answer thanks to namespacing. There was lengthy, but inconclusive, discussion about this a year ago: http://thread.gmane.org/gmane.comp.version-control.git/165799/focus=166290 M. ``` ## Nathan Gray, 2012-04-26 23:33 Subject: Re: Why aren't tag refs namespaced? Message-ID: URL: https://gitlist.dev/e/CA%2B7g9JzpLkNHT_o1QyJ_r%3D4DrauWOPFr5XR_CPeAHGcLpLoD%2Bw%40mail.gmail.com In-Reply-To: ``` On Thu, Apr 26, 2012 at 12:24 PM, Junio C Hamano wrote: > Nathan Gray 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 ``` ## Nathan Gray, 2012-04-26 23:34 Subject: Re: Why aren't tag refs namespaced? Message-ID: URL: https://gitlist.dev/e/CA%2B7g9JxpLs9rqRpacmLvnJ-2mZPCT%2BBwd8J4-vp27HCZPTS0pA%40mail.gmail.com In-Reply-To: <4F99AACC.2050409@xiplink.com> ``` On Thu, Apr 26, 2012 at 1:06 PM, Marc Branchaud wrote: > > There was lengthy, but inconclusive, discussion about this a year ago: > > http://thread.gmane.org/gmane.comp.version-control.git/165799/focus=166290 Thanks for the reference. I'll give that a read. 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 ``` ## Nathan Gray, 2012-04-26 23:48 Subject: Re: Why aren't tag refs namespaced? Message-ID: URL: https://gitlist.dev/e/CA%2B7g9Jy24VRO9Tr0o_4RNZN05fhyn5TZLo1C74CK%2BLbZduCJbw%40mail.gmail.com In-Reply-To: ``` CC'ing the list On Thu, Apr 26, 2012 at 12:04 PM, Phil Hord wrote: > On Thu, Apr 26, 2012 at 2:40 PM, Nathan Gray wrote: >> Namespacing works really well for branch refs.  I know that >> remotes/origin/master is origin's master branch.  I may or may not >> have a master branch, and it may or may not have anything in common >> with origin's.  Our repositories are independent, after all, so it >> makes sense that our refs would live in different namespaces. >> >> So why is it that tag refs don't follow this model? > > I expect the simple answer is that no one has been motivated to create > such a mode. > > >> Why is my >> "best-commit-ever" tag assumed to be the same as origin's?  Given a >> ref in refs/tags it's unclear if the ref is public, private, on origin >> or not on origin.  Will pushing my tags create anything new or not? >> Who knows?  Compare this to branches, where the same questions are >> easy to answer thanks to namespacing. >> >> OTOH, am I just not "getting it?"  I've been using git for about 4 >> years now and I feel like I know it pretty well but it's possible I'm >> just misunderstanding things. > > > Tags are presumed not to move, so there's no point in having a remote > tag which you follow with your local tag.  In that sense, they are > fundamentally different from branches.  Also, tags are not pushed by > default, though they are fetched if they're on branches you are > fetching. All that is true, but... > On the other hand, it does invite namespace collisions if > you pull tags from a remote whilst having local tags and no > agreed-upon convention. Exactly! Imagine tracking 5 different forks of the same project on GitHub. They can't be expected to coordinate their tagging conventions. > But perhaps a convention is what you need.  Suppose you name all your > local tags "refs/tags/n8gray/best-commit-ever"?  Or maybe you can 'git > fetch origin "refs/tags/*:refs/tags/origin/*"'. That could probably be made to work, but it requires a fair bit of effort to keep clean. Plus you have to make sure you never accidentally use the built-in tag pushing/pulling stuff or it all falls apart. 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 ``` ## Junio C Hamano, 2012-04-27 03:26 Subject: Re: Why aren't tag refs namespaced? Message-ID: URL: https://gitlist.dev/e/xmqq62cl7t40.fsf%40junio.mtv.corp.google.com In-Reply-To: ``` Nathan Gray writes: >> 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. Yeah, as I said, the current behaviour aims to support a particular workflow, e.g. * "git fetch --tags" uses a built-in refspec "refs/tags/*:refs/tags/*" and that maps a tag at the remote to the same location in the refs/ hierarchy in the local repository. * "git fetch" that stores the history it fetches to local repository (i.e. uses refspec with non-empty RHS), when run without "--no-tags", fetches tags that point at commits in the fetched history from the remote and stores them at the same location in the refs/ hierarchy. and does it well. But there is nothing in Git that fundamentally forces you to follow that pattern. It is entirely plausible to enhance the former (i.e. --tags) to a bool-or-string option to let you specify different refs/ hierarchy (e.g. "--tags" would use "refs/tags/*:refs/tags/*" to map the names, while "--tags=refs/remotes/origin/tags" might store fetched tags in specified place that is different from refs/tags/), and to add a new option to specify where the auto-followed tags would be stored to enhance the latter. ```