Re: nits with new _git

[Mikael Magnusson <mikachu@xxxxxxxxx>]

On 17 May 2011 14:56, Nikolai Weibull <now@xxxxxxxx> wrote:
> On Sat, May 14, 2011 at 03:28, Mikael Magnusson <mikachu@xxxxxxxxx> wrote:
>> Now that pws fixed the crash, I'm updating to the new _git, so far
>> I've noticed these two things.
>>
>> git log --pret<tab> goes into correction, same for git show.
>> % git log --pretty=
>> ---- option
>> --pretty  -- pretty print commit messages
>> ---- corrections (errors: 2)
>> --grep    -- limit commits to those with log messages matching the given pattern
>> --pretty  -- pretty print commit messages
>>
>> Usually this would hint at some missing ret=0 somewhere, but I
>> couldn't find any. Unconditionally returning 0 from _git does 'fix' it
>> though, so it must be somewhere.
>
> I can’t reproduce this issue.

This was sort of a mindfuck, but I figured it out :). It looks like
this is a systematic error in the whole _git file, but should be
easily fixed. _git() itself defines local ret=1, then does
_call_function ret _git-$words[1], then _git-log() in this case sets
ret=0 on success. Sounds good? Not really, because it doesn't return
ret, so then _call_function overwrites ret with something else. The
solution would seem to simply not use _call_function since none of the
helper functions return anything, they just set ret directly.

--- a/Completion/Unix/Command/_git
+++ b/Completion/Unix/Command/_git
@@ -6023,11 +6023,11 @@ _git() {
       (option-or-argument)
         curcontext=${curcontext%:*:*}:git-$words[1]:

-        _call_function ret _git-$words[1]
+        _git-$words[1]
         ;;
     esac
   else
-    _call_function ret _$service
+    _$service
   fi
   return ret
 }



-- 
Mikael Magnusson