From: Vincent Mailhol Date: Thu, 13 Aug 2026 13:45:03 GMT Subject: Re: [PATCH v2 2/4] completion: complete 'git history --empty' values Message-ID: In-Reply-To: <00E5CBDB-7D2A-4117-9A52-FD5C64A9838C@gmail.com> On Thu. 13 Aug. 2026 at 13:12, Ben Knoble wrote: > > Le 13 août 2026 à 04:20, Vincent Mailhol a écrit : > > > > On Mon. 10 Aug. 2026 at 14:50, D. Ben Knoble wrote: > >> One other thing, sorry > >> > >>> On Thu, Aug 6, 2026 at 4:36 PM Vincent Mailhol 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