Re: Slowness issue with git completion

[Mikael Magnusson <mikachu@xxxxxxxxx>]

On 26 April 2011 23:10, Felipe Contreras <felipe.contreras@xxxxxxxxx> wrote:
> On Tue, Apr 26, 2011 at 11:59 PM, Mikael Magnusson <mikachu@xxxxxxxxx> wrote:
>>>> 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 "--".

It's only slow in repos as large as the linux one.

> 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.

Because you don't want to complete unchanged files when adding?

-- 
Mikael Magnusson