On Mon, 7 Feb 2011, Jeff King wrote: > 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. Agreed. > Will the same apply to refs/heads/foo versus refs/remotes/*/foo? I think it should. If both branches are pointing to the same commit then the short form "foo" should be unambigous and the operation proceed (be that 'git push' or 'git log' that shouldn't matter). > 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?). In such a case I'd say that head refs have precedence over tag refs, and when that occurs then warn the user. And I wouldn't make a special case for 'git push' here. Whether it is push or log, the head ref would take precedence, and the user warned about existence of a tag with the same name. Of course using "tag/foo" should be unambigous again. > So the actual names of the ref can matter, > and should probably be taken into account when deciding what is > ambiguous. What happens today when you have refs/heads/foo and refs/tags/foo? 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