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