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@xxxxxxxxxxx>
www.herland.net
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html