Re: [1.8.0] Provide proper remote ref namespaces

From: Dmitry Potapov <dpotapov@gmail.com>
Date: Feb 7, 2011, 00:07 UTC
Message-ID: <AANLkTi=A-rh+wfg7O4KryydxVuorM8nkuGYmpbgVfVJp@mail.gmail.com>
In-Reply-To: <201102062312.51655.johan@herland.net>

On Sun, Feb 06, 2011 at 11:12:51PM +0100, Johan Herland wrote:

>
> Yes, technically git 1.7.4 is a myth. However, by convention, we all agree
> what "v1.7.4" points to, and nobody seriously believe they can get away with
> pointing "v1.7.4" somewhere else.

There are two sorts of tags:
- local tags, which are never intended to be shared with others but used
  by users to mark some points in the working repository.
- global tags, which are just _social_convention_ about what the current
  project considers as official versions. Without social convention, they
  make no sense.

Show 6 quoted lines

> The core of this discussion is where we want to place Git in the space
> between "technically correct" and "socially conventional", where the former
> means owning up to the fact that each repo really is its own namespace, and
> there's no way around that in a proper DVCS, and the latter means building
> social convention into our tools, thereby making it harder to deal with the
> few unconventional cases (like my two semi-related repos case).

Tags like words are social convention, which are used for communication between people participated in a project. But accordingly to you, it seems somehow "technically correct" to invent their own words in Humpty Dumpty's ways:

'When I use a word,' Humpty Dumpty said, in rather a scornful tone, 'it means just what I choose it to mean — neither more nor less.'

I am afraid you got the wrong idea about "proper DVCS", because DVCS does not imply that there is no social convention. It just means that there is no single authority that dictates everything. Like with words, there is no single authority that assigns meaning to new words, but that does not mean that you cannot just say "When I use a word... " if you want to be understood by others.

Show 5 quoted lines

>
> AFAICS, my proposal does not harm the common case (unambiguous tags are
> still interpreted unambiguously, even if they may exist in multiple
> namespaces), while it _does_ help the uncommon case (by allowing ambiguous
> tags to co-exist in the same repo).

It hurts the common case in a few ways:
1. It breaks existing user scripts
2. It complicates things for users (as Matthieu wrote above).
3. git fetch cannot report a tag clash if it happens

Show 5 quoted lines

>
> Granted, if we leave all tags in a single namespace, I can still work around
> this by manually futzing with the configured refspecs to create ad hoc
> namespaces. But I _really_ hate it when I'm forced to hack around the tool,
> because the tool thinks it "knows better".

I believe that the right interface when the common case is simple, but an uncommon case is still possible to handle. I don't think that currently git meets this criterion, but making tag namespaces based on the remote name strikes me as a really bad idea. Tags are attributes of a project and not particular remote.

Show 11 quoted lines

>
> > 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.
>
> My proposal tries very hard to present a single namespace _semantically_ to
> the user in the common case (when tags are unambiguous). I'd even go as far
> as proposing that "git tag -l" should by default list only a single
> shortened tag name in the cases where there are multiple unambiguous
> alternatives.

IMHO, it is very confusing, especially for people whose script was suddenly broken by those namespaces.

Show 6 quoted lines

>
> Alternatively, I'd suggest a compromise (already mentioned elsewhere in this
> thread) where we add a config variable tags.preferredRemote (defaults to
> "origin") which allows you to directly select which namespace you consider
> official. You could even implement this as physically copying
> refs/remotes/${tag.preferredRemote}/tags/* into refs/tags/*.

It seems you do not understand the problem that I am trying to say all way along: there is more than one repo from which I fetch tags, and because they are belong to the same project, they should be in the same namespace.

So, IMHO, the proper solution should be ability to specify the desired namespace for any remote repository, like this:

remote.<name>.tagNameSpace = foo

So, those who want to have many namespaces should be able to that easily, but forcing multiple namespaces on those who have a single namespace semantically is simple wrong. Not to mention that it breaks existing scripts for no good reason.

Show 17 quoted lines

>
> > > 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.
>
> Again, you are setting "technical correctness" up against "social
> convention". Technically, _any_ ref name whatsoever is repo-specific and
> "completely useless for communication with other people". The only thing we
> can communicate unambiguously is SHA-1 object names. However, social
> conventions compel us to name our refs unambiguously and to use common sense
> when communicating, so that - in practice - everybody in the project knows
> exactly what is meant by "v1.0".

Public tags are purely social convention. If there is no convention, they are completely meaningless, and we can use only SHA-1. Thus speaking about technical correctness of tags makes no sense.

Dmitry