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