Re: [1.8.0] Provide proper remote ref namespaces
- From
Jeff King <peff@peff.net>
- Date
- Feb 7, 2011, 05:11 UTC
- Message-ID
- <20110207051123.GA4748@sigill.intra.peff.net>
- In-Reply-To
- <201102070451.37370.johan@herland.net>
On Mon, Feb 07, 2011 at 04:51:37AM +0100, Johan Herland wrote:
Show 9 quoted lines
> > 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:
Show 5 quoted lines
> 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