On Thu, Apr 9, 2009 at 10:18, Jeff King <peff@xxxxxxxx> wrote: > 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. Right, and the idea was to choose the alternatives based on the core.warnAmbiguousRefs setting, i.e. the former for false, the latter for true. For what I posted a patch some time ago: http://thread.gmane.org/gmane.comp.version-control.git/96464 (which I read though now) Bert > > -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