Re: [1.8.0] Provide proper remote ref namespaces

[Nicolas Pitre <nico@fluxnic.net>]

On Sat, 5 Feb 2011, Jeff King wrote:

> On Sat, Feb 05, 2011 at 01:39:57PM -0500, Nicolas Pitre wrote:
> 
> > So that's what has to be fixed.  If you get duplicated tag names then 
> > just warn the user and give priority to the local one, or error out with 
> > a "ambiguous tag specification" if no local but multiple remote tags 
> > with the same name are found (the user would have to be more precise in 
> > the tag scope in that case).
> 
> The latter seems like a regression for the common case of fetching from
> two upstreams. E.g., I usually pull from Junio, getting
> remotes/origin/v1.7.0.  One day Shawn is the interim maintainer, and I
> pull from him, getting remotes/spearce/v1.7.0, which he previously
> fetched from Junio. Under the current code, I can still do "git show
> v1.7.0"; under the scheme described above I now have to say
> "origin/v1.7.0" to disambiguate.

Let's suppose that both tags are identical, as in your scenario above 
they would be, then there is no need to call for any ambiguity in that 
case.

> The real issue, I think, is that we are claiming ambiguity even though
> those tags almost certainly point to the same sha1. When handling
> ambiguous tags, should we perhaps check to see if all of the ambiguities
> point to the same sha1, and in that case, just pick one at random?

If they're identical then there is no randomness.  If they refer to 
different tag objects, even if those tag objects do refer to the same 
commit object, then I'd say there is an ambiguity only if the tag object 
content matters i.e. when displaying the tag content.

> In the case of resolving a ref to a sha1, then by definition they are
> all equivalent to pick. For things that care (e.g., "git checkout") we
> should probably still complain (although many of those commands have
> their own disambiguation code to prefer refs/heads/ or whatever anyway).

We are probably more or less saying the same thing.


Nicolas