Re: [1.8.0] Provide proper remote ref namespaces

[Johan Herland <johan@herland.net>]

On Monday 07 February 2011, Jeff King wrote:
> On Mon, Feb 07, 2011 at 04:51:37AM +0100, Johan Herland wrote:
> > > Take the example of the interim maintainer cited somewhere else in
> > > this thread. If Shawn fetches from Junio, he'll get a junio/v1.7.4
> > > tag, and on my side, I do not want to end up having
> > > shawn/junio/v1.7.4, especially if this means that people fetching
> > > from me would end up with a me/shawn/junio/v1.7.4 ...
> > 
> > You won't end up with "shawn/junio/v1.7.4". When Shawn fetches from
> > Junio, what he actually gets is "refs/remotes/junio/tags/v1.7.4"
> > ("junio/v1.7.4" is a shorthand; "v1.7.4" is an even better shorthand).
> 
> But keep in mind that this proposal will have to live alongside repos
> that are using older versions of git. So Shawn might very well have
> refs/tags/v1.7.4 from Junio if he is using (or has ever used) pre-1.8.0
> git.

Yes, but since they point to the same object, there's no ambiguity.

I'm also starting to wonder whether we should, in existing repos with 
existing remotes, keep using the old-style refspecs by default, thereby 
making new-style refspecs the default only for _new_ repos. It seems mixing 
the two styles in one repo would cause confusion. Another alternative would 
be to transform old-style remotes into new-style remotes, but I believe that 
was shot down elsewhere in this thread.

> No, that won't give you me/shawn/junio/v1.7.4, but it does mean we have
> to gracefully handle the case of ambiguous duplicate tags (that happen
> to point to the same thing).

Whoa, we use the "ambiguous" term differently here. In this whole thread I 
have used "ambiguous" exclusively about when the same (shorthand) tag name 
point to _different_ things. As long as they point to the same thing, there 
is no ambiguity, IMHO.

> Which I think you are implying here:
> > Next, you should never pull from Shawn's work repo, but rather from the
> > repo he has published. In that repo he will typically have pushed the
> > "v1.7.4" tag (as described above). When you pull from Shawn's public
> > repo, you will get the "v1.7.4" tag at
> > "refs/remotes/shawn/tags/v1.7.4" (but "v1.7.4" is an unambigious
> > shorthand).
> 
> But I wanted to point it out explicitly.

Yes, over its lifetime a tag name ("v1.7.4") might appear in several 
namespaces (refs/tags, refs/remotes/*/tags), but it's always identifiable 
with the shorthand "v1.7.4" name (assuming no other "v1.7.4" name point to a 
different object).

This is the same technique we use when talking about branch names: On this 
mailing list, nobody is confused when I refer to 'maint', 'master', 'next' 
and 'pu'. Still, in our own work repos (at least in mine), these branches 
are actually called "refs/remotes/origin/<name>" (commonly referred to by 
their shorthands "origin/<name>"). Here we are, juggling the same kind of 
namespaces that I propose for tags, and it seems to work well without 
causing much confusion.


...Johan

-- 
Johan Herland, <johan@herland.net>
www.herland.net