Re: [1.8.0] Provide proper remote ref namespaces

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Monday 07 February 2011, Matthieu Moy wrote:
> Johan Herland <johan@xxxxxxxxxxx> 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, <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


[Index of Archives]     [Linux Kernel Development]     [Gcc Help]     [IETF Annouce]     [DCCP]     [Netdev]     [Networking]     [Security]     [V4L]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux SCSI]     [Fedora Users]