On Tue, Apr 07, 2009 at 09:39:58AM +0200, Bert Wesarg wrote: > > Actually, I am not quite sure that this function is "more correct". It > > looks at the rev-parsing rules as a hierarchy, so if you have > > "refs/remotes/foo" and "refs/heads/foo", then it will abbreviate the > > first to "remotes/foo" (as expected) and the latter to just "foo". > > > > This is technically correct, as "refs/heads/foo" will be selected by > > "foo", but it will warn about ambiguity. Should we actually try to avoid > > reporting refs which would be ambiguous? > Back than, there was the idea that the core.warnAmbiguousRefs config > could be used for this. I'm not quite sure what you mean. Using this function, we may shorten an unambiguous name to one that will complain if core.warnAmbiguousRefs is set. So what I'm wondering is if it should use a different algorithm that produces a shortened ref which will not cause a warning. E.g., right now if we have: refs/heads/master refs/remotes/master showing %(refname:short) gets you: master remotes/master but "git show master" will warn about the ambiguous ref (but still show you the one you want). An alternative would be to show: heads/master remotes/master in this case. -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