Re: Slowness issue with git completion

[Felipe Contreras <felipe.contreras@xxxxxxxxx>]

On Wed, Apr 27, 2011 at 12:13 AM, Mikael Magnusson <mikachu@xxxxxxxxx> wrote:
> 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.

No. It's slow everywhere, it's *dead* slow on Linux. And BTW, there's
thousands of developers working on Linux (the kernel), I guess we are
not important.

I just tried on one of my projects that has only 67 files, it took
almost two seconds. That's completely unacceptable; you are blowing
git's performance away.

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

Didn't you just said "if the command works, we should complete it"?

But what is the real advantage? That only one file would be listed
instead of a couple? Well, that would be nice, if it didn't take 10
seconds to do that. I would rather pick the right file myself, that's
faster.

Moreover, if you really want that, it's much easer to first find the
local files, and _then_ find they have been unchanged.

time git ls-files --modified --other -z -- > /dev/null (0m7.640s)
time git ls-files --modified --other -z -- 'M*' > /dev/null (0m2.224s)

That's dropping caches.

Cheers.

-- 
Felipe Contreras