On Sun, Feb 06, 2011 at 05:11:45PM +0100, Johan Herland wrote: > On Sunday 06 February 2011, Dmitry Potapov wrote: > > On Sun, Feb 06, 2011 at 01:04:36AM +0100, Johan Herland wrote: > > >_ > > > > > > 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.) > >_ > > I see no reason to create different namespaces, because semantically > > there is only one namespace. >_ > In practice, there is almost always one namespace (i.e. your repo belongs to_ > only one project with project-wide unique tags). However, in any distributed_ > system, the only-one-namespace is fundamentally a myth. By your logic git 1.7.4 is a myth, because I have not specified from what repository I pull it. But, IMHO, it is a myth that having different namespaces solves the problem, because in _most_ cases, you really want to have a single namespace _semantically_, so you can communicate with other people using this tag name. In your case of semi-related projects, it should be two namespaces, because there are _two_ different projects (even if they share a lot of common history). How do I know that they are different? Because they have different release schedulers, and v1.0 means different for each of them. > > To me, the proper handling ambiguity means that when I do "git fetch" I > > immediately see warning about tag clashes. So, I agree with you that > > current behavior is not good, but I disagree with you about having many > > namespaces, because it postpones detection of the conflict until I try > > to use. And well, git may detect ambiguity when I say "git show v1.0", > > but if I look at my branch in gitk and see "v1.0" and may say to someone > > that I use "v1.0" but that person looks at his tree and sees "v1.0" as > > something different. >_ > In that case it would be wrong of gitk to display "v1.0". Instead it should_ > display a longer, unambiguous name, e.g. "origin/v1.0". But it is still ambiguous because my "origin" may be different from yours origin. It is only unambiguous when it look at it _locally_ but that makes it completely useless for communication with other people. One project should have only one version with the same tag regardless where it came from. I agree in your use case of semi-related projects you need separate namespaces. But I don't think it is how most people use git. It may be nice to have an option that will make tag namespace separate, but I do not think it should be default. Not until, it is widely tested. Dmitry -- 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