All of lore.kernel.org
 help / color / mirror / Atom feed
From: Nathan Gray <n8gray@n8gray.org>
To: Phil Hord <phil.hord@gmail.com>
Cc: git@vger.kernel.org
Subject: Re: Why aren't tag refs namespaced?
Date: Thu, 26 Apr 2012 16:48:33 -0700	[thread overview]
Message-ID: <CA+7g9Jy24VRO9Tr0o_4RNZN05fhyn5TZLo1C74CK+LbZduCJbw@mail.gmail.com> (raw)
In-Reply-To: <CABURp0okZ=-sq7e0ReUepCOEUC=9r2845wQ6H3HhruRg8Jd6Dg@mail.gmail.com>

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

      parent reply	other threads:[~2012-04-26 23:48 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-04-26 18:40 Why aren't tag refs namespaced? Nathan Gray
2012-04-26 19:24 ` Junio C Hamano
2012-04-26 23:33   ` Nathan Gray
2012-04-27  3:26     ` Junio C Hamano
2012-04-26 20:06 ` Marc Branchaud
2012-04-26 23:34   ` Nathan Gray
     [not found] ` <CABURp0okZ=-sq7e0ReUepCOEUC=9r2845wQ6H3HhruRg8Jd6Dg@mail.gmail.com>
2012-04-26 23:48   ` Nathan Gray [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=CA+7g9Jy24VRO9Tr0o_4RNZN05fhyn5TZLo1C74CK+LbZduCJbw@mail.gmail.com \
    --to=n8gray@n8gray.org \
    --cc=git@vger.kernel.org \
    --cc=phil.hord@gmail.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.