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, <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