Re: [1.8.0] Provide proper remote ref namespaces

From: Dmitry Potapov <dpotapov@gmail.com>
Date: Feb 8, 2011, 01:06 UTC
Message-ID: <20110208010648.GA3132@dpotapov.dyndns.org>
In-Reply-To: <201102070429.05033.johan@herland.net>

On Mon, Feb 07, 2011 at 04:29:04AM +0100, Johan Herland wrote:

Show 7 quoted lines

> 
> As I understand your view (I do apologize if I somehow misrepresent it), you 
> want Git to assume that the common practice of one semantic namespace is 
> followed. Furthermore, you also want to enforce that practice where 
> possible, while still improving the handling of the uncommon (but 
> theoretically inevitable) case (warning and presumably guiding the user when 
> a tag conflict occurs).

Yes, you are correct. I consider a single tag namespace as the common case, but it should be possible to have more than one namespace for those who needs that. I think our disagreement is due to the fact that you believe that if someone added another remote, he or she wants another namespace for tags, but I think it depends on whether you treat different remotes as one project or different semi-related projects.

There is a fundamental difference between branches and tags is that branches are often different (like each co-worker can publish each own master that he or she tested), but tags should have same tags as long as we work on the same project, otherwise it will lead to confusion.

Show 6 quoted lines

> 
> > 2. It complicates things for users (as Matthieu wrote above).
> 
> I guess this depends on your POV. Fundamentally, I do NOT want to change how 
> people refer to tags. I only want to provide them the possibility of doing 
> so when ambiguity is present.

IMHO, there are two fundamentally two different use cases:
- one project with many remotes
- two (probably semi-related) projects in the same repo

In the first case, having two tags pointing to different commits is an obvious mistake that should be fixed as soon as possible. I do not think that different namespaces are necessary to fix that (or at least I do not see how it helps), but my main concern was that resolution of a tag conflict may be postponed (because they appear in different namespaces), but that does not resolve the confusion and may only prolong it.

Show 9 quoted lines

> 
> > 3. git fetch cannot report a tag clash if it happens
> 
> Yes it can: For each tag fetched from the remote, if resolving its shorthand 
> name ("v1.7.4") results in ambiguity (i.e. there exists a conflicting tag 
> elsewhere in this repo), then warn the user about this conflict, and explain 
> how to refer to each tag candidate using the full ref name. Also explain how 
> the user may resolve the ambiguity by creating a local tag 
> ("refs/tags/v1.7.4") pointing to the preferred target.

It it is possible then I do not have any serious objection here...

Show 9 quoted lines

> > So, IMHO, the proper solution should be ability to specify the desired
> > namespace for any remote repository, like this:
> > 
> > remote.<name>.tagNameSpace = foo
> 
> Interesting. I'm not sure what "foo" means in this context. Would I use it 
> like this?:
> 
>     remote.origin.tagNameSpace = refs/tags

I was not sure about the specific when I wrote this, so I just put "foo", but it could be something like you wrote above.

Show 6 quoted lines

> 
> (to place origin's tags in refs/tags/*)
> 
> If so, what's the difference between this option, and using this?:
> 
>     remote.origin.fetch = refs/tags/*:refs/tags/*

I have not tried that, but I suspect that it will cause that all tags will be fetched even if they are not belong to tracked branches, i.e. "git fetch" will work as "git fetch -t". But maybe I am wrong here.

Dmitry