Why aren't tag refs namespaced?

Why aren't tag refs namespaced?

[Nathan Gray]

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

Re: Why aren't tag refs namespaced?

[Junio C Hamano]

Nathan Gray <n8gray@n8gray.org> 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.

Re: Why aren't tag refs namespaced?

[Marc Branchaud]

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.

Re: Why aren't tag refs namespaced?

[Nathan Gray]

On Thu, Apr 26, 2012 at 12:24 PM, Junio C Hamano <gitster@pobox.com> wrote:
> Nathan Gray <n8gray@n8gray.org> 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

Re: Why aren't tag refs namespaced?

[Nathan Gray]

On Thu, Apr 26, 2012 at 1:06 PM, Marc Branchaud <marcnarc@xiplink.com> 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

Re: Why aren't tag refs namespaced?

[Nathan Gray]

CC'ing the list

On Thu, Apr 26, 2012 at 12:04 PM, Phil Hord <phil.hord@gmail.com> wrote:
> On Thu, Apr 26, 2012 at 2:40 PM, Nathan Gray <n8gray@n8gray.org> 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

Re: Why aren't tag refs namespaced?

[Junio C Hamano]

Nathan Gray <n8gray@n8gray.org> 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.