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

From: Jeff King <peff@peff.net>
Date: Apr 9, 2009, 08:18 UTC
Message-ID: <20090409081857.GC17221@coredump.intra.peff.net>
In-Reply-To: <36ca99e90904070039m15869c34jc9e12d5ccc48d82@mail.gmail.com>

On Tue, Apr 07, 2009 at 09:39:58AM +0200, Bert Wesarg wrote:

Show 10 quoted lines

> > 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