Re: [1.8.0] Provide proper remote ref namespaces

[Johan Herland <johan@herland.net>]

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@herland.net>
www.herland.net