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

From: Jeff King <peff@peff.net>
Date: Nov 4, 2022, 13:00 UTC
Message-ID: <Y2UM6S+QUFkhz5d4@coredump.intra.peff.net>
In-Reply-To: <76c585d22bf415e719762fcf5decf4b71efa5bfb.1667561761.git.congdanhqx@gmail.com>

On Fri, Nov 04, 2022 at 06:40:12PM +0700, Đoàn Trần Công Danh wrote:

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

Right.

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

I think it won't interfere. A user can't put "--" as a separator now; it gets taken as part of the command. So if we consistently added one in the caller and stripped it away in bisect--helper, that would work correctly (and if the user did have one later in their command, it would be preserved as it is now).

That said, I do think your solution is nicer, and is potentially fixing similar problems in other subcommand modes, too.

> Let's parse subcommand with OPT_SUBCOMMAND since that API was born for
> this specific use-case.

The implication here being that OPT_SUBCOMMAND stops parsing as soon as it hits a subcommand, I assume.

>  builtin/bisect--helper.c    | 86 +++++++------------------------------
>  git-bisect.sh               | 20 ++++-----

The patch here looks sensible, but...

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
> +'

...since you removed --log in the first commit, I think this would pass even before this patch. You'd need to use another option like --bisect-reset to show the problem. Of course then it is trivial that the patch fixes it, since "--bisect-reset" becomes "bisect-reset" afterwards. So there are no options left to parse at that point. But it would be the best we could do to demonstrate it.

-Peff