Re: Slowness issue with git completion

[Felipe Contreras <felipe.contreras@xxxxxxxxx>]

On Tue, Apr 26, 2011 at 9:43 PM, Frank Terbeck <ft@xxxxxxxxxxxxxxxxxxx> wrote:
> Felipe Contreras wrote:
>> It's very easy to reproduce:
>> % git clone git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6.git
>> linux
>> % cd linux
>> % git log v<tab>
>>
>> It will take a looong time to figure out anything, specially if not
>> cached. I think I recall investigating the issue and finding that it's
>> looking for *all* the files in the git repo.
>
> Well yes. This is a known issue.
>
> I'm fairly sure that this is due to _multi_parts, which probably doesn't
> scale for jobs like that.  I once gave rewriting all that a shot and
> ended up with a number of helpers for each "type" of file etc. (like
> modified or ignored files).  While they were significantly quicker than
> the current code, they were probably still full of bugs and
> shortcomings. Also, I would have had to rewrite *large* parts of the
> rest of the completion, which would have been a *major* undertaking.
>
> In short: It's a known issue and it's very hard to fix (if only because
> it is a *lot* of work).

Here's a quick solution: don't try to list files. If I want to list
files, I would use '-- '. And in fact, that's exactly what the bash
completion does.

Moreover, why do you want to be smarter than git? There are ways to
ask git precisely what we want: list the contents of certain tree-ish
on-demand. And in fact, that's exactly what the bash completion does:

time git ls-tree HEAD -- (0m0.005s)
time git ls-tree HEAD -- drivers/ (0m0.007s)

Seriously, this is very annoying.

-- 
Felipe Contreras