Re: [PATCH] _git-grep: Complete files when outside git repos

["Daniel Shahaf" <d.s@daniel.shahaf.name>]

Mikael Magnusson wrote on Fri, 25 Sep 2020 06:49 +00:00:
> On 9/25/20, Daniel Shahaf <d.s@daniel.shahaf.name> wrote:
> > Guido Cella wrote on Thu, Sep 24, 2020 at 22:34:41 +0200:
> >> ---
> >>  Completion/Unix/Command/_git | 6 ++++++
> >>  1 file changed, 6 insertions(+)
> >>
> >> diff --git a/Completion/Unix/Command/_git b/Completion/Unix/Command/_git
> >> index 05e2a23..67f06c5 100644
> >> --- a/Completion/Unix/Command/_git
> >> +++ b/Completion/Unix/Command/_git
> >> @@ -1037,6 +1037,12 @@ _git-grep () {
> >>    # don't complete treeishs.
> >>    case $state in
> >>      (tree-or-file)
> >> +      # Check if we're not in a git repository.
> >> +      if ! git rev-parse 2>/dev/null; then
> >> +        _files && ret=0
> >> +        return ret
> >> +      fi
> >
> > Why is this correct?  When cwd isn't a repository, «git grep foo ./bar»
> > just errors out:
> > .
> >     % ls
> >     iota
> >     % git grep This iota
> >     fatal: not a git repository (or any parent up to mount point /)
> >     Stopping at filesystem boundary (GIT_DISCOVERY_ACROSS_FILESYSTEM not
> > set).
> >     zsh: exit 128
> >
> > Does newer git behave differently?  If not, shouldn't the behaviour be
> > conditional on --no-index having been passed?
> 
>   grep.fallbackToNoIndex
>     If set to true, fall back to git grep --no-index if git grep is executed
>     outside of a git repository. Defaults to false.
> 
> [...] it seems easier to just complete files in this
> context since git can be configured to accept them here.

Fair enough.  In this case, the patch should be revised to use
_call_program (and possibly discard stdout?).

> I guess if we want to be fancy we can check for this option / command
> line switch, [...]

If we wanted to be fancy, we'd parse the output of `git config --null`
into an associative array at the top of _git, so all _git-foo()
functions would be able to check such things cheaply.  (May want to make
this conditional on some opt-in style for performance reasons?)

Cheers,

Daniel