Re: [PATCH v2 2/4] completion: complete 'git history --empty' values

From: Ben Knoble <ben.knoble@gmail.com>
Date: Aug 13, 2026, 11:12 UTC
Message-ID: <00E5CBDB-7D2A-4117-9A52-FD5C64A9838C@gmail.com>
In-Reply-To: <CAMZ6RqLAYMSwNK=w=Xh+O==46eQCS=wFgBoUEOtQoBbLrBqd_A@mail.gmail.com>

Show 31 quoted lines

> Le 13 août 2026 à 04:20, Vincent Mailhol <mailhol@kernel.org> a écrit :
> 
> On Mon. 10 Aug. 2026 at 14:50, D. Ben Knoble <ben.knoble@gmail.com> wrote:
>> One other thing, sorry
>> 
>>> On Thu, Aug 6, 2026 at 4:36 PM Vincent Mailhol <mailhol@kernel.org> wrote:
>>> 
>>> diff --git a/contrib/completion/git-completion.bash b/contrib/completion/git-completion.bash
>>> index 7372e2919b..fe5223b8ec 100644
>>> --- a/contrib/completion/git-completion.bash
>>> +++ b/contrib/completion/git-completion.bash
>>> @@ -2171,8 +2171,17 @@ _git_history ()
>>>        fi
>>> 
>>>        if ! __git_has_doubledash; then
>>> -               case "$cur" in
>>> -               --*)
>>> +               case "$prev,$cur" in
>>> +               --empty,*|*,--empty=*)
>>> +                       case "$subcommand" in
>>> +                       drop|fixup)
>> 
>> This feels a bit "inside out" to me, especially when reading the other
>> completions. I think the usual pattern is to check the subcommand
>> first and dispatch if necessary. Thoughts?
> 
> The motivation is to have a single:
> 
>  case "$cur" in
> 
> statement.

I now suspect this is why some use the « case "$subcommand,$cur" » variant ? Apologies for not thinking of that previously.