Re: [PATCHv2 07/14] completion: don't disambiguate short refs

[Jeff King <peff@peff.net>]

On Thu, Mar 23, 2017 at 04:29:17PM +0100, SZEDER Gábor wrote:

> However, it's questionable whether ambiguous refs are really that bad
> to justify that much extra cost:

It's not clear to me that the existing completion actually does a good
job with disambiguation anyway.

If I have a tag and a branch named "foo", then in theory doing:

  git log fo<Tab>

should present me with "heads/foo" and "tags/foo" as options. But it
doesn't seem to; it just completes "foo".

But even if it did, those don't _start_ with foo, I have to go to some
work to back up anyway. I think we are better off just completing "foo"
and letting the command complain that it's ambiguous.

So even leaving aside the performance tradeoff, that seems like a more
sensible behavior anyway. And AFAICT, that's the behavior you'd get with
your patch (we'd get two "foo"s, but the completion is presumably smart
enough to handle that.

> This speeds up refs completion considerably.  Uniquely completing a
> branch in a repository with 100k local branches, all packed, best of
> five:
> 
>   On Linux, before:
> 
>     $ time __git_complete_refs --cur=maste
> 
>     real    0m1.662s
>     user    0m1.368s
>     sys     0m0.296s
> 
>   After:
> 
>     real    0m0.831s
>     user    0m0.808s
>     sys     0m0.028s

This is nice, though I think faster ref storage is another way to attack
the problem. This is much simpler, though. :)

-Peff