zsh-workers
 help / color / mirror / code / Atom feed
From: Torstein Hegge <hegge@resisty.net>
To: zsh-workers@zsh.org
Subject: Re: [PATCH] git: Pass prefix filter to ls-files even if it matches no files
Date: Sat, 20 Apr 2013 21:00:56 +0200	[thread overview]
Message-ID: <20130420190056.GA5650@pvv.ntnu.no> (raw)
In-Reply-To: <20130317123525.GB30500@pvv.ntnu.no>

On Sun, Mar 17, 2013 at 13:35:25 +0100, Torstein Hegge wrote:
> When a branch or tag name is completed with zsh in a large git repo, the
> completion is slow if the given prefix doesn't match a file or directory in
> the current working directory. Testing with linux.git, which contains release
> tags like v3.9 and a directory virt/:
> 
>   git log v<tab>
> 
> takes about 0.5 seconds, while
> 
>   git log v3<tab>
> 
> takes about 25 seconds.
> 
> (Timed using zsh 4.3.17, on a fairly slow cpu. zsh from git appears to be
> quite a bit faster, but the difference between completing v and v3 is still
> large.)
> 
> The difference between the two is that v<tab> passes the result of v* to git
> ls-files while v3<tab> determines that v3* matches no files, and passes an
> empty prefix to git ls-files. So git ls-files lists all files in the repo
> and passes that on to _multi_parts.
> 
> Making git do the expansion of the * after the prefix lets git ls-files v3*
> return an empty list, making _multi_parts job easier.
> 
> This does not affect the behavior of git log <tab>, but improves the
> performance of partial tag and branch tab-completion in the common case where
> file names and tag/branch names don't overlap.
> ---

No interest in this? Or did I miss something obvious?

>  Completion/Unix/Command/_git |    2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/Completion/Unix/Command/_git b/Completion/Unix/Command/_git
> index 2b6a369..d736367 100644
> --- a/Completion/Unix/Command/_git
> +++ b/Completion/Unix/Command/_git
> @@ -5339,7 +5339,7 @@ __git_files () {
>    # TODO: --directory should probably be added to $opts when --others is given.
>  
>    local pref=$gitcdup$gitprefix$PREFIX
> -  files=(${(0)"$(_call_program files git ls-files -z --exclude-standard $opts -- ${pref:+$pref\*} 2>/dev/null)"})
> +  files=(${(0)"$(_call_program files git ls-files -z --exclude-standard $opts -- ${pref:+$pref\\\*} 2>/dev/null)"})
>    __git_command_successful $pipestatus || return
>  
>  #  _wanted $tag expl $description _files -g '{'${(j:,:)files}'}' $compadd_opts -
> -- 
> 1.7.10.4
> 
> 


  reply	other threads:[~2013-04-20 19:44 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-03-17 12:35 Torstein Hegge
2013-04-20 19:00 ` Torstein Hegge [this message]
2013-04-20 20:31   ` Frank Terbeck
2013-04-21  6:09     ` Nikolai Weibull

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20130420190056.GA5650@pvv.ntnu.no \
    --to=hegge@resisty.net \
    --cc=zsh-workers@zsh.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this public inbox

	https://git.vuxu.org/mirror/zsh/

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).