On 2022-11-04 14:46:18+0100, Ævar Arnfjörð Bjarmason <avarab@xxxxxxxxx> wrote:
>
> On Fri, Nov 04 2022, Đoàn Trần Công Danh wrote:
>
> > As of it is, we're parsing subcommand with OPT_CMDMODE, which will
> > continue to parse more options even if the command has been found.
> >
> > When we're running "git bisect run" with a command that expecting
> > a "--log" or "--no-log" arguments, or one of those "--bisect-..."
> > arguments, bisect--helper may mistakenly think those options are
> > bisect--helper's option.
> >
> > We may fix those problems by passing "--" when calling from
> > git-bisect.sh, and skip that "--" in bisect--helper. However, it may
> > interfere with user's "--".
> >
> > Let's parse subcommand with OPT_SUBCOMMAND since that API was born for
> > this specific use-case.
>
> If we go for this approch over my series, let's pretty please...
>
> > + OPT_SUBCOMMAND("bisect-reset", &fn, cmd_bisect__reset),
> > + OPT_SUBCOMMAND("bisect-terms", &fn, cmd_bisect__terms),
>
> Not call this "bisect-reset" etc, but just "reset", the whole point of
> the greater problem here is...
Yes, we should strip "bisect-" from those sub-commands.
>
> > - git bisect--helper --bisect-start "$@" ;;
> > + git bisect--helper bisect-start "$@" ;;
>
> ...to be able to eventually remove this shimmy layer completely,
> which...
>
> > bad|good|new|old|"$TERM_BAD"|"$TERM_GOOD")
> > - git bisect--helper --bisect-state "$cmd" "$@" ;;
> > + git bisect--helper bisect-state "$cmd" "$@" ;;
>
> ...as you can see in my
> https://lore.kernel.org/git/patch-12.13-13745e3f18f-20221104T132118Z-avarab@xxxxxxxxx/
> we still need to handle this special snowflake, but...
>
>
> > skip)
> > - git bisect--helper --bisect-skip "$@" || exit;;
> > + git bisect--helper bisect-skip "$@" || exit;;
> > next)
> > # Not sure we want "next" at the UI level anymore.
> > - git bisect--helper --bisect-next "$@" || exit ;;
> > + git bisect--helper bisect-next "$@" || exit ;;
> > visualize|view)
> > - git bisect--helper --bisect-visualize "$@" || exit;;
> > + git bisect--helper bisect-visualize "$@" || exit;;
> > reset)
> > - git bisect--helper --bisect-reset "$@" ;;
> > + git bisect--helper bisect-reset "$@" ;;
> > replay)
> > - git bisect--helper --bisect-replay "$@" || exit;;
> > + git bisect--helper bisect-replay "$@" || exit;;
>
> ...instead of doing all of this, get rid of most of this case statement, and just do:
>
> bad|good|...)
> [...]
> *)
> git bisect--helper "$cmd" "$@"
> ;;
>
> > log)
> > - git bisect--helper --bisect-log || exit ;;
> > + git bisect--helper bisect-log || exit ;;
>
> But note that there are subtle behavior differences in some,
> e.g. because we do the "|| exit" we'll eat the exit code, and this one
No, there're nothing different between "|| exit" and simply run the
command, since "|| exit" will exit with old exit status code.
I don't think there're any other different.
> also doesn't get parameters, so it should be left out of such a list
> (see tests in my topic for a regression check for that, we're currently
> flying blind in that area).
>
> > +# We want to make sure --log is not eaten
> > +test_expect_success '"git bisect run" simple case' '
> > + git bisect start &&
> > + git bisect good $HASH1 &&
> > + git bisect bad $HASH4 &&
> > + git bisect run printf "%s\n" --log >my_bisect_log.txt &&
> > + grep -e --log my_bisect_log.txt &&
> > + git bisect reset
> > +'
>
> Check out my 1/13 to see all the cases you missed:
> https://lore.kernel.org/git/patch-01.13-beb1ea22a27-20221104T132117Z-avarab@xxxxxxxxx/
> :)
--
Danh
