Re: [PATCH 4/5] make get_short_ref a public function

[Jeff King <peff@peff.net>]

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