On Tue, Aug 02 2022, Junio C Hamano wrote: > SZEDER Gábor <szeder.dev@xxxxxxxxx> 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).
