Re: [1.8.0] Provide proper remote ref namespaces
- From
Johan Herland <johan@herland.net>
- Date
- Feb 7, 2011, 08:58 UTC
- Message-ID
- <201102070958.11551.johan@herland.net>
- In-Reply-To
- <20110207051123.GA4748@sigill.intra.peff.net>
On Monday 07 February 2011, Jeff King wrote:
Show 15 quoted lines
> 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.
Show 9 quoted lines
> 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