Hi Junio, On Mon, 25 Jul 2022, Junio C Hamano wrote: > SZEDER Gábor <szeder.dev@xxxxxxxxx> 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
