Re: Slowness issue with git completion

[Felipe Contreras <felipe.contreras@xxxxxxxxx>]

On Tue, Apr 26, 2011 at 11:59 PM, Mikael Magnusson <mikachu@xxxxxxxxx> wrote:
> On 26 April 2011 22:57, Felipe Contreras <felipe.contreras@xxxxxxxxx> wrote:
>> On Tue, Apr 26, 2011 at 11:34 PM, Mikael Magnusson <mikachu@xxxxxxxxx> wrote:
>>> On 26 April 2011 22:23, Felipe Contreras <felipe.contreras@xxxxxxxxx> wrote:
>>>> 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.
>>>
>>> git accepts files with or without a --
>>
>> So?
>
> So if the command works, we should complete it.

Even if it's so slow that it is unusable? I don't understand the urge
to have that, nobody seems to be complaining about that behavior with
the bash completion. Even git itself warns when you have a ref and a
file that are ambiguous; you need to manually add "--".

BTW. The actual behavior is: if there's a ref, go for refs, if there's
no ref, try the files. So 'git show v' first would show the version
refs, but 'git show vi' will show the 'virt' directory. I don't see
how that is so atrocious. You can still auto-complete commands that
work.

>>>> 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)
>>>
>>> git ls-tree doesn't allow you to filter the output files by 'changed',
>>> 'new', 'unknown' etc etc.
>>
>> So?
>
> So we can use ls-tree for log i guess, but not for much else, git add
> will still be slow for example.

Why do you need any git command at all to find completions for 'git
add'? Just use the normal local file completion.

-- 
Felipe Contreras