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. > 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. 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. So, if there is two different tags with the same name, it is better to report the problem as soon as possible, i.e. during "git fetch", and then there is no reason to have separate namespaces for tags. 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