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