Re: [PATCH] usage: clarify --recurse-submodules as a boolean

From: Junio C Hamano <gitster@pobox.com>
Date: Apr 8, 2023, 00:59 UTC
Message-ID: <xmqqy1n3fat2.fsf@gitster.g>
In-Reply-To: <ZDCztVHuZoCstNar@google.com>

Emily Shaffer <nasamuffin@google.com> writes:

Show 6 quoted lines

> I think we do because config_update_recurse_submodules is static to
> submodule.c - that is, builtin/checkout.c and friends don't have access
> to set it manually with OPT_BOOL. Using the callback just to set static
> state we don't naturally have access to is pretty awful, though, so I'd
> be in favor of plumbing it through like other options we might be
> passing to the submodule machinery.

Yes, the cleanest way to interface into that part of the submodule machinery that wants to use a hidden static state would be to

 (1) implement a setter interface in the submodule machinery for
     that hidden static state, and

 (2) use the bog-standard OPT_BOOL() on an on-stack variable of
     cmd_checkout() and friends, and use that setter interface after
     parse_options() returns.

Then you can avoid the "pretty awful" arrangement today's code has.

Note that such a clean-up can be done independent of how an option that yields a Boolean value can be spelled, i.e. whether we'd accept --frotz=yes or only take --[no-]frotz.