On Sat, Feb 05, 2011 at 02:55:06PM -0500, Nicolas Pitre wrote:
> > 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...
> > 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
--
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