On Sunday 06 February 2011, Dmitry Potapov wrote:
> On Sun, Feb 06, 2011 at 05:11:45PM +0100, Johan Herland wrote:
> > 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.
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.
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).
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).
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".
> 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.
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/*.
> > 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".
It seems our opinions differ on whether Git should try to _force_ this
social convention on you, or rather stick to technical correctness (with a
bias towards conventional behavior as long as there no ambiguities).
> 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.
Well, this _is_ the thread for discussing things "we would have done
differently if we were writing Git from scratch". ;)
Still, you have yet to convince me exactly _what_ will in practice be
horribly and user-visibly broken by this proposal. AFAICS, all the common
use cases today will still work well with this proposal.
...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