Zsh Mailing List Archive
Messages sorted by:
Re: Slowness issue with git completion
- X-seq: zsh-workers 29064
- From: Felipe Contreras <felipe.contreras@xxxxxxxxx>
- To: Mikael Magnusson <mikachu@xxxxxxxxx>
- Subject: Re: Slowness issue with git completion
- Date: Wed, 27 Apr 2011 00:10:10 +0300
- Cc: Frank Terbeck <ft@xxxxxxxxxxxxxxxxxxx>, zsh-workers@xxxxxxx, Nikolai Weibull <now@xxxxxxxx>
- Dkim-signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=3EQWjzFBnw67RoOGK8k3j5X08tISm+ebflptu/KuCPI=; b=vs3jtvVsa/cB69eKAy7DvRTjQdJ8p0rIG0bqad5eFgpKIN8Ng16IDrxEIomq6Hp8pR O2yAcU6Gvp2HdM/uyXoIGz5uqHTKHuHcXveyMloJRWtoCvz46heBGMcFwfiknUXFW14s fvqZyTw1x66+qUDExwSueC+6u9U7hjd/TspMg=
- Domainkey-signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=uFqb7P7y2v2k70zsvrcEIourdZE/pq7HJnhV7/Hzi/sgQ14FX13uUbqwRSZsN2BOwn Ry7I4saAwB3yT6vWWxKgbb95oZE5s9bMRZxBg1NLd9Lc0TCjLtXuquGGUemQ3dzxe8wN T23iO2Wz7q8Hyhx2VJjptEi6elJpyrhxTOwFU=
- In-reply-to: <BANLkTi=N0DjXbf70LCo422DQ_2b0_dK_AQ@mail.gmail.com>
- List-help: <mailto:firstname.lastname@example.org>
- List-id: Zsh Workers List <zsh-workers.zsh.org>
- List-post: <mailto:email@example.com>
- Mailing-list: contact zsh-workers-help@xxxxxxx; run by ezmlm
- References: <BANLkTinKo=W8umz=JfneD3MNYdmv=xYhFQ@mail.gmail.com> <firstname.lastname@example.org> <BANLkTim6WJWCrfLokA045Sc8su8DMXnKNw@mail.gmail.com> <BANLkTi=eLWad_TB4L=chD=3Fb_Pd9AQyqQ@mail.gmail.com> <BANLkTi=PrLsikjVhA-e06gjEkkxDpsdVaw@mail.gmail.com> <BANLkTi=N0DjXbf70LCo422DQ_2b0_dK_AQ@mail.gmail.com>
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
>>>>>> % 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 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
>>>> 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 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.
Messages sorted by: