Re: [1.8.0] Provide proper remote ref namespaces

[Dmitry Potapov <dpotapov@gmail.com>]

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