Re: [PATCH 00/20] parse-options: handle subcommands
- From
Johannes Schindelin <johannes.schindelin@gmx.de>
- Date
- Jul 26, 2022, 15:42 UTC
- Message-ID
- <1p04q351-9938-r0r7-snr6-9s8237s27459@tzk.qr>
- In-Reply-To
- <xmqq5yjl5b4y.fsf@gitster.g>
Hi Junio,
On Mon, 25 Jul 2022, Junio C Hamano wrote:
Show 12 quoted lines
> SZEDER Gábor <szeder.dev@gmail.com> writes: > > > - builtin/bisect.c: after the conversion/rename from 'bisect--helper', > > cmd_bisect() doesn't use parse-options anymore. Take what's on 'seen' > > to resolve the conflict. > > Note that the conflicting topic should have marked cmd_bisect() with > > the NO_PARSEOPT flag in 'git.c's command list. > > I was wondering about this one. Does the new "subcommand" support > help implementing the dispatching to subcommands better? If so it > may not be a bad idea to redo the cmd_bisect() on top of this series > once it proves to be solid.
The built-in `bisect` code carries around some local state, in a somewhat futile attempt to keep things in a state that would be more amenable to libifying.
The `subcommand` series does not accommodate for such a local state, the signature `typedef int parse_opt_subcommand_fn(int argc, const char **argv, const char *prefix);` requires all pre-subcommand options to be parsed into global (or file-local, but not function-local) variables.
This implies that moving `cmd_bisect()` on top of the `subcommand` topic would require the `bisect` code to become less libifyable, which is an undesirable direction.
Ciao, Dscho