Subject: Re: [PATCH 01/20] git.c: update NO_PARSEOPT markings

From: Ævar Arnfjörð Bjarmason <[email-masked]>
Date: Wed, 03 Aug 2022 15:11:13 +0200

On Tue, Aug 02 2022, Junio C Hamano wrote:

> SZEDER Gábor <[email-masked]> writes:
>
>> Dunno.  I don't like this NO_PARSEOPT thing, and instead of testing it
>> I'm thinking about removing it altogether.
>
> Sorry if this is obvious to the others, but I am confused here.
>
> Lack of NO_PARSEOPT bit is used as a mark to say "this subcommand
> takes '--git-completion-helper' option to help listing the options,
> so include it in the 'git --list-cmds=parseopt' output", right?  I
> do not mind removing an unused or unnecessary bit at all, but what
> is your plan of getting rid of the bit?  Will we make sure everybody
> supports the "--git-completion-helper" option?

We could:

 * Handle it in git-completion.bash itself, e.g. send-email supports
   --git-completion-helper but isn't a built-in, the git-completion.bash
   itself knows it can be invoked with it.

 * We could just try to run the command with --git-comletion-helper, and
   fall back if it returns 128 or 129. AFAICT the only ones we'd need to
   handle specially would be rev-list (returns 0) and fast-import (will
   hang, expecting stdin input).

The non-parse_options() supporting ones are rare enough these days (and
we've been ~quickly converting them) that perhaps an on-the-fly check
would be fine (and we cache the result, as with most/all other such
checks in git-completion.bsah).