Re: [PATCH 3/3] bisect--helper: parse subcommand with OPT_SUBCOMMAND

From: Ævar Arnfjörð Bjarmason <avarab@gmail.com>
Date: Nov 4, 2022, 13:46 UTC
Message-ID: <221104.86mt96ygj9.gmgdl@evledraar.gmail.com>
In-Reply-To: <76c585d22bf415e719762fcf5decf4b71efa5bfb.1667561761.git.congdanhqx@gmail.com>

On Fri, Nov 04 2022, Đoàn Trần Công Danh wrote:

Show 14 quoted lines

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

> -		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@gmail.com/ we still need to handle this special snowflake, but...

Show 16 quoted lines

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

Show 9 quoted lines

> +# 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@gmail.com/ :)