On Mon, Feb 07, 2011 at 09:53:29AM -0500, Nicolas Pitre wrote: > > But more importantly, don't we sometimes care where the ref came from? > > Not at the moment. Certainly not with the current flat namespace used > for tags. I'm not sure I was clear. I didn't mean "which remote the ref came from" but rather "when choosing between two refs, don't we sometimes care about the actual name of the ref?". But see below. > > 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". > > How can this matter? The same automagic on the destination ref may > still take place. Semantically you want to push v1.7.4 so nothing has > to change there, irrespective of the namespace the v1.7.4 tag comes > from. This doesn't matter today, so why would this particular case need > to change? I guess the problem is that I'm not clear on exactly what the new lookup / ambiguity rules are proposed to be. Clearly something will need to go in the dwim_ref level. And I think it's obvious that if "refs/tags/foo" and "refs/remotes/*/tags/foo" point to the same sha1, they will not be considered ambiguous. Will the same apply to refs/heads/foo versus refs/remotes/*/foo? Will it also apply to refs/heads/foo versus refs/remotes/*/tags/foo? In the final case, that does matter to "git push" (should the destination be in the head or tag namespace?). So the actual names of the ref can matter, and should probably be taken into account when deciding what is ambiguous. Maybe that was obvious to everybody and it was an implicit part of the proposal, but it wasn't clear to me. -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