On Mon, 30 Sep 2013, Marc Branchaud wrote:

> Why would there be ambiguity warnings?  The fetch command shouldn't issue any
> warnings, since all the remotes' names get safely tucked away in distinct
> namespaces.
> Are we talking about DWIM warnings?  Aside from git-describe I don't see why
> such warnings would be a problem.  To DWIM-resolve a tag name look in
> refs/tags/* and refs/remotes/*/tags/* -- much like it's done for branches
> already.  If a tag name has multiple matches then it's ambiguous.  Git could
> be clever and check for matching SHA1 values, but why bother?  It almost
> seems like a disservice to silently disambiguate such names.  I would think a
> user would prefer to know about any possible ambiguities, rather than have
> some suddenly appear (and maybe also disappear).

Consider that I have in my Linux kernel tree:

- a remote branch corresponding to Linus' master tree

- multiple remote branches corresponding to Linux stable branches

- a remote for linux-next which is a repo constantly being rebased

Now all those repositories share the mainline tags from Linus' repo and 
they add some more of they own which are not shared.  So if they all 
have a v3.11 tag that resolve to the same SHA1, then there is 
effectively no ambiguity at all and git should not warn at all.

*However* if one of those v3.11 tags does not agree with the others 
_then_ I want to be warned about it.

So having multiple matching tags that do resolve to the same SHA1 across 
different remote repositories _is_ the norm and should work 

To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Reply via email to