Why aren't tag refs namespaced?

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

Nathan Gray <n8gray@n8gray.org> writes:

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.

On Thu, Apr 26, 2012 at 12:24 PM, Junio C Hamano <gitster@pobox.com> wrote:

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.

That makes sense.

Cheers, -n8

Nathan Gray <n8gray@n8gray.org> writes:

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.

On 12-04-26 02:40 PM, Nathan Gray wrote:

There was lengthy, but inconclusive, discussion about this a year ago:

http://thread.gmane.org/gmane.comp.version-control.git/165799/focus=166290

		M.

On Thu, Apr 26, 2012 at 1:06 PM, Marc Branchaud <marcnarc@xiplink.com> wrote:

Thanks for the reference. I'll give that a read. Cheers, -n8

CC'ing the list

On Thu, Apr 26, 2012 at 12:04 PM, Phil Hord <phil.hord@gmail.com> wrote:

All that is true, but...

Exactly! Imagine tracking 5 different forks of the same project on GitHub. They can't be expected to coordinate their tagging conventions.

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