From: Johannes Schindelin <johannes.schindelin@gmx.de>
Date: Tue, 26 Jul 2022 15:42:01 GMT
Subject: Re: [PATCH 00/20] parse-options: handle subcommands
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:

> 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