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

[Bert Wesarg <bert.wesarg@googlemail.com>]

On Thu, Apr 9, 2009 at 10:18, Jeff King <peff@peff.net> 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
>