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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Fri, Nov 04, 2022 at 06:40:12PM +0700, Đ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.

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

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



[Index of Archives]     [Linux Kernel Development]     [Gcc Help]     [IETF Annouce]     [DCCP]     [Netdev]     [Networking]     [Security]     [V4L]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux SCSI]     [Fedora Users]

  Powered by Linux