Re: Approximate file path completion for git?

[Bart Schaefer <schaefer@brasslantern.com>]

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 -