Zsh Mailing List Archive
Messages sorted by:
Re: Slowness issue with git completion
- X-seq: zsh-workers 29061
- From: Mikael Magnusson <mikachu@xxxxxxxxx>
- To: Felipe Contreras <felipe.contreras@xxxxxxxxx>
- Subject: Re: Slowness issue with git completion
- Date: Tue, 26 Apr 2011 22:34:15 +0200
- 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; bh=hTC+KdWawKdfrnfhdKhBQO0Scva5kxXEwnrIONjklww=; b=N5YiVRwuPIw5Jv/nFulrSJ+vm2q0cN8tMa1y851J4u2Z96GyXY26Lv/c4khmdp9kn7 vlHqt7ucPR5/7dqKJaBpeIYNKrn5BHCfwgf5LtHXf2mZTf3+7aXyGNutHD3Aih79j48j wlLp9nzfKJsCJrWxo5NtSTcLN4sifyUPKJbtg=
- 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; b=UwawtIM98WoQXW3n60J1j7kC/skVu6wdtO6bi/4d5dW5bgDRWVxvtb0Dns/7BwOKNq WtIjJnN+NiUL1MJk4NoUS4kA8Z6FfhTlUePfGwFMvW8EF2K2g6GO4FkK5KG0D+7d1SJk MhCMb79i1XkDefOpRi6/qzAuGMW2ZHX1uITr4=
- In-reply-to: <BANLkTim6WJWCrfLokA045Sc8su8DMXnKNw@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>
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 --
> 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.
> Seriously, this is very annoying.
This type of comment is not productive.
Messages sorted by: