On Sun, 6 Feb 2011, Dmitry Potapov wrote: > To me, the proper handling ambiguity means that when I do "git fetch" I > immediately see warning about tag clashes. Fair enough. > 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. No. The later does not prevent the former. > 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. If gitk is smart enough to see that two tags have the same name then it should scope them so they are not ambiguous anymore, unless of course they are referring to the same thing in which case they are not ambiguous from the start. > 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. Of course there is a reason. What if your fetch brings in hundreds of tags (this is common for some projects) and then you want to remove that fetched branch from your repository? How do you determine which tag came from that remote repository and which tags are to be kept? Without a separate namespace this is practically impossible. Nicolas -- 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