Re: [PATCH v2 00/14] Finish converting git bisect into a built-in

["Ævar Arnfjörð Bjarmason" <avarab@gmail.com>]

On Fri, Feb 25 2022, Johannes Schindelin wrote:

> Hi Junio,
>
> On Wed, 23 Feb 2022, Junio C Hamano wrote:
>
>> [...] the parse-options bit I am not sure about (read: I do not have a
>> strong objection, but I do have to wonder if there is a better way to
>> achieve the goal) [...]
>
> After spending a lot of time to try to make it work, I realized that it's
> in the name of `parse_options()` that it's not a `handle_subcommand()`
> API.
>
> So yes, I agree there is probably a better way (and e.g. `git bundle`
> and `scalar` would benefit from it, too): designing a proper API for
> handling subcommands.
>
> That's safely outside the scope of the patch series, of course.

I think SZEDER has some out-of-tree patches to do that, for what it's
worth.

But it's not emit_usage_info() either (at least not directly), and we
also use it for that.

So this seems like a distraction from the feedback I provided on your
patch.

Which for one is that due to bugs in the conversion things that emitted
usage errors before are now silently accepted.

And that whatever we do to make things *easier* for
bundle/stash/commit-graph etc. when it comes to this, doesn't explain
why you feel the need to introduce yet another pattern of doing this,
when the existing "handle subcommands" built-ins do it rather uniformly,
and AFAICT there's nothing in the "git bisect" case that's special
enough that it wouldn't be served by pretty much copying that template.