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.
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).
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.
-Peff
--
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