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

On Thu. 13 Aug. 2026 at 13:12, Ben Knoble <[email protected]> wrote:
> > Le 13 août 2026 à 04:20, Vincent Mailhol <[email protected]> a écrit :
> >
> > On Mon. 10 Aug. 2026 at 14:50, D. Ben Knoble <[email protected]> wrote:
> >> One other thing, sorry
> >>
> >>> On Thu, Aug 6, 2026 at 4:36 PM Vincent Mailhol <[email protected]> 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 ?

IMHO,

  case "$subcommand,$cur"

is not very elegant. Sometimes, it is a good trade-off, but here, it
does not seem to be the best solution. Of course, maybe some future
changes in git history would make this a preferable option, but I do
not have a crystal ball to predict the future.

> Apologies for not thinking of that previously.

No problem :)


Yours sincerely,
Vincent Mailhol