Subject: Re: [1.8.0] Provide proper remote ref namespaces

From: Johan Herland <[email-masked]>
Date: Mon, 07 Feb 2011 04:51:37 +0100

On Monday 07 February 2011, Matthieu Moy wrote:
> Johan Herland <[email-masked]> writes:
> >> For tags, it's clearly different. If I have origin/v1.7.4, I don't see
> >> much reason to have _also_ v1.7.4 as a local tag. And if I have only
> >> origin/v1.7.4 and push it as origin/v1.7.4, then someone pulling from
> >> it will get origin/origin/v1.7.4, and so on.
> > 
> > Wrong. If you have origin/v1.7.4, it's because v1.7.4 already exists in
> > the origin remote, so there's no point in trying to push it back. On
> > the other hand, if you have v1.7.4 locally (but not origin/v1.7.4),
> > you should (assuming this is intended to be a public tag) consider
> > pushing it to the "origin" remote, thus causing origin/v1.7.4 to
> > appear in your repo.
> 
> (I made a bad choice by repeating "origin" several times)
> 
> What happens if I pull from "remoteA" and then push to "remoteB"?

So, when you pull from "remoteA", you get 
"refs/remotes/remoteA/tags/v1.7.4", but since it is unambiguous, you can 
refer to it by "v1.7.4" instead.

When you push to "remoteB", you would say "git push remoteB tag v1.7.4", and 
it would resolve "v1.7.4" (via "refs/remotes/remoteA/tags/v1.7.4") into the 
appropriate SHA-1, and then push the "v1.7.4" tag to the remote.

You have to separate the namespace from the name itself. For instance, if I 
run "git push remoteB tag v1.7.4", it resolves "v1.7.4" into 
refs/tags/v1.7.4, but that doesn't mean that I end up with 
"refs/tags/refs/tags/v1.7.4" in the "remoteB" repo.

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

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

Even if you _were_ to pull directly from Shawn's work repo, you would not 
get the "shawn/junio/v1.7.4" mess you fear, simply because when you fetch 
from a repo, the refs inside that repo's "refs/remotes" are not fetched.

...Johan

-- 
Johan Herland, <[email-masked]>
www.herland.net