Re: [PATCH v3 11/15] bisect: move even the command-line parsing to `bisect--helper`

From: Ævar Arnfjörð Bjarmason <avarab@gmail.com>
Date: May 21, 2022, 16:52 UTC
Message-ID: <220521.86zgjazuy4.gmgdl@evledraar.gmail.com>
In-Reply-To: <4ae78d37d04789b2cadb059088e59af80a850c15.1653144546.git.gitgitgadget@gmail.com>

On Sat, May 21 2022, Johannes Schindelin via GitGitGadget wrote:

Show 7 quoted lines

> From: Johannes Schindelin <johannes.schindelin@gmx.de>
>
> On our journey to a fully built-in `git bisect`, this is the
> one of the last steps.
>
> Side note: The `parse-options` API is not at all set up to parse
> subcommands such as `git bisect start`, `git bisect reset`, etc.

It seems that since v2 you fixed the bug of "-h" starting a bisection session, as noted in : https://lore.kernel.org/git/220225.86ilt27uln.gmgdl@evledraar.gmail.com/

But that problem seems to still be with us in other forms, e.g. just one
thing I tried (the very first thing) was the command I was testing in
10/15, and:
    
    ./git bisect--helper  --bisect-terms 1 2 ; echo $?
    You need to start by "git bisect start"
    
    Do you want me to do it for you [Y/n]? ^C

so that's buggy too.

> Instead of fighting an up-hill battle trying to "fix" that, we simply
> roll the same type of manual subcommand parsing as we already do e.g.
> in `builtin/bundle.c`.

This is particularly confusing because that would be a good approach (as I pointed out in a previous round), but the end-state here isn't at all like builtin/bundle.c. I.e. in that case we have a top-level strcmp() chain dispatching to parse_options() for the sub-command, which would solve your problems here...