From: Ævar Arnfjörð Bjarmason <avarab@gmail.com>
Date: Sat, 21 May 2022 16:52:22 GMT
Subject: Re: [PATCH v3 11/15] bisect: move even the command-line parsing to `bisect--helper`
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:

> 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...