Re: [1.8.0] Provide proper remote ref namespaces

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

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.

quoted

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.

quoted

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...

quoted

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.

(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