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

From: Johan Herland <[email-masked]>
Date: Sun, 06 Feb 2011 01:04:36 +0100

On Saturday 05 February 2011, Dmitry Potapov wrote:
> On Sat, Feb 05, 2011 at 02:18:44AM +0100, Johan Herland wrote:
> > Having said that, there are real situations where users encounter
> > collisions in the shared tag namespace. A rare (but plausible)
> > scenario arise when two developers create (and publish) conflicting
> > tags in their repos. A more common scenario that I have encountered at
> > $dayjob, is where two parallel (semi-related) projects are developed
> > in separate repos (with different versioning because of separate
> > release schedules), and I need to interface with both repos from a
> > single local repo. Each of the remote repos have their own "v1.0" tag,
> > but my repo can only hold one such tag. Which of those tags end up
> > "winning" in my local repo depends on my fetch order.
> 
> Well, I agree that this situation requires a better diagnostic, but I
> don't think that having separate namespaces is the right solution in
> general. For your case, where you work on semi-related projects, it is
> could be the right thing to do, but if you work on the same project and
> have more than one source to fetch, then having multiple namespaces can
> lead only to confusion, because tag names must be unique globally to
> make sense to everyone. Actually, even if you have two semi-related
> projects in the same repository, but you have more than one URL per
> project, you want to group tags based on their relation to the project
> and not based on the URL.

I'm not sure what problem you're describing here. Let's assume that my repo 
has multiple remotes (URLs), but they're all fundamentally part of the same 
project. If there is a tag "foo" in one remote/namespace, and a tag "foo" in 
a different remote/namespace, they (in the common case) point to the same 
object, since they - as you say - "must be unique globally to make sense to 
everyone".

As long as they point to the same object, there's no ambiguity, and when you 
simply refer to tag "foo" (without specifying namespace) it all works, like 
today. (Read footnote [2] of my proposal for more details on handling 
ambiguity in tag names.)

However, when the remote tags point to different objects (i.e. the uncommon 
case), there is an ambiguity, and we should deal with that ambiguity 
properly, instead of silently adopting one of them arbitrarily.

I don't see how the separate namespaces cause problems here. Also, I don't 
know what you're proposing instead, or indeed what other organization of 
tags would lead to less confusion.

Have fun! :)

...Johan

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