Approximate file path completion for git?

Approximate file path completion for git?

[Keerthan jai.c]

[-- Attachment #1: Type: text/plain, Size: 175 bytes --]

Hi,

I'm unable to use approximate path completion for git.
Example: % git add a/b/c<TAB>

Is this a bug, or has this feature been disabled for git?

-- 
have a nice day
-jck

Re: Approximate file path completion for git?

[Bart Schaefer]

On Jan 10, 11:50pm, Keerthan jai.c wrote:
}
} I'm unable to use approximate path completion for git.
} Example: % git add a/b/c<TAB>
} 
} Is this a bug, or has this feature been disabled for git?

Hmm, this looks as though it may have been broken by workers/31159
which was intended to speed up access to remote repositories.

It's attempting to use a/b/c as a prefix, when what's needed for
partial-path completion (which is not quite the same as approximate
completion) is to actually fetch all the files, even if from a remote
repository, so they can be tested against the partial paths.  Yes,
this is going to be really slow if the remote repo is large, but it
is required for partial paths (unless 'git ls-files' is going to
pick up the ability to do it).

31159 got first overlooked and then hastily pushed when it was pointed
out that it had been overlooked.  It should have gotten a bit more
testing ...

Probably what we need here is either a zstyle to let the user choose
whether path completion works, or to simply attempt ls-files a second
time without the prefix if the first attempt doesn't give any results.
I'm not going to try to guess which of those is better as I'm not that
familiar with git behavior, particularly on large repos.

Re: Approximate file path completion for git?

[Bart Schaefer]

On Jan 10,  9:34pm, Bart Schaefer wrote:
}
} Hmm, this looks as though it may have been broken by workers/31159
} 
} Probably what we need here is either a zstyle to let the user choose
} whether path completion works, or to simply attempt ls-files a second
} time without the prefix if the first attempt doesn't give any results.

Here's a third possibility that occurred to me.  This backs out 31159
and then adds the no_nomatch option when running git ls-files.  Maybe
that satisfies Torstein's issues?  It restores partial path completion
in some cases that I found to be failing before.


diff --git a/Completion/Unix/Command/_git b/Completion/Unix/Command/_git
index 43a01d9..9e364c8 100644
--- a/Completion/Unix/Command/_git
+++ b/Completion/Unix/Command/_git
@@ -5683,7 +5683,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)"$(setopt no_nomatch; _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 -

Re: Approximate file path completion for git?

[Bart Schaefer]

On Jan 10, 11:37pm, Bart Schaefer wrote:
}
} -  files=(${(0)"$(_call_program files git ls-files -z --exclude-standard $opts -- ${pref:+$pref\\\*} 2>/dev/null)"})
} +  files=(${(0)"$(setopt no_nomatch; _call_program files git ls-files -z --exclude-standard $opts -- ${pref:+$pref\*} 2>/dev/null)"})

That needs nullglob turned off as well.  Here's a corrected patch:


diff --git a/Completion/Unix/Command/_git b/Completion/Unix/Command/_git
index 43a01d9..e9a5318 100644
--- a/Completion/Unix/Command/_git
+++ b/Completion/Unix/Command/_git
@@ -5683,7 +5683,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)"$(unsetopt nullglob nomatch; _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 -

Re: Approximate file path completion for git?

[Keerthan jai.c]

[-- Attachment #1: Type: text/plain, Size: 1356 bytes --]

Backing out 31159 and unsetopt nomatch; works for me. However, unsetopt
nullglob breaks it again.


On Sat, Jan 11, 2014 at 12:58 PM, Bart Schaefer
<schaefer@brasslantern.com>wrote:

> On Jan 10, 11:37pm, Bart Schaefer wrote:
> }
> } -  files=(${(0)"$(_call_program files git ls-files -z --exclude-standard
> $opts -- ${pref:+$pref\\\*} 2>/dev/null)"})
> } +  files=(${(0)"$(setopt no_nomatch; _call_program files git ls-files -z
> --exclude-standard $opts -- ${pref:+$pref\*} 2>/dev/null)"})
>
> That needs nullglob turned off as well.  Here's a corrected patch:
>
>
> diff --git a/Completion/Unix/Command/_git b/Completion/Unix/Command/_git
> index 43a01d9..e9a5318 100644
> --- a/Completion/Unix/Command/_git
> +++ b/Completion/Unix/Command/_git
> @@ -5683,7 +5683,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)"$(unsetopt nullglob nomatch; _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 -
>



-- 
have a nice day
-jck

Re: Approximate file path completion for git?

[Bart Schaefer]

On Jan 11,  5:13pm, Keerthan jai.c wrote:
}
} Backing out 31159 and unsetopt nomatch; works for me. However, unsetopt
} nullglob breaks it again.

Drat, I thought I'd tried this and seen differently.  no_nomatch without
no_nullglob is a no-op, effectively just backing out 31159 without doing
anything in its place.  Apparently the only way to get both the prefix
completion speed desired by some and the partial completion accuracy
desired by others is to try both routes, fastest first, which is likely
actually even slower for the accuracy crowd.