On Sat, May 21 2022, Johannes Schindelin via GitGitGadget wrote: > From: Johannes Schindelin <johannes.schindelin@xxxxxx> > > 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@xxxxxxxxxxxxxxxxxxx/ 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...
