Re: [1.8.0] Provide proper remote ref namespaces

From: Jeff King <peff@peff.net>
Date: Feb 7, 2011, 05:18 UTC
Message-ID: <20110207051834.GB4748@sigill.intra.peff.net>
In-Reply-To: <alpine.LFD.2.00.1102051449420.12104@xanadu.home>

On Sat, Feb 05, 2011 at 02:55:06PM -0500, Nicolas Pitre wrote:

Show 11 quoted lines

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

Agreed, but...

Show 9 quoted lines

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

My gut feeling is that they should point to the same tag object, for the sake of simplicity (if you are re-tagging a commit under the same name, wouldn't I want to know?) and efficiency (we can detect non-ambiguity just by looking at the sha1 values without opening objects).

But more importantly, don't we sometimes care where the ref came from? If I say "git push remote v1.7.4" we do some automagic on the destination side of the refspec based on the fact that the source ref was found in the refs/tags hierarchy. In the case we're talking about, all of the ambiguous refs would presumably also be coming from refs/remotes/*/tags/, so they would be functionally equivalent. But I wanted to point it out because:

  1. It is an additional equivalent requirement for two refs to not be
     ambiguous. They must have the same sha1, _and_ they must have the
     same "type".

  2. I couldn't think of any other cases where the actual refname might
     matter and this would break. But I wanted to bring it up explicitly
     in case somebody else can think of one.

-Peff