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. Sure, it's a convenient myth, and one that we - with good reason - strive towards fulfilling, but there are situations (described earlier in this thread) where the myth is busted. In those situations, I think the _least_ confusing thing we can do for our users is to handle all remote refs consistently, and allow them to discover/investigate the remote tags as they would other remote refs. > > 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. 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". > 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. Yes, that is an alternative solution for tags. I guess it comes down to a question of how much special treatment we want to give tags. I'd rather have consistency between how tags and other remote refs are handled. ...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