On Fri, Nov 04 2022, Jeff King wrote: > On Fri, Nov 04, 2022 at 07:31:26AM +0100, Lukáš Doktor wrote: > >> Steps to Reproduce: >> >> 1. git bisect start BAD GOOD >> 2. git bisect run ./myscript arg1 --log arg2 --log -- arg3 --log arg4 >> >> Results with 2.34.1: >> >> running './myscript' 'arg1' 'arg2' '--' 'arg3' '--log' 'arg4' >> >> Results with 2.33.0: >> >> running ./myscript arg1 --log arg2 --log -- arg3 --log arg4 > > Thanks for an easy reproduction recipe. I used this as an easy-to-see > test case, which works in any repo: > > git bisect start HEAD HEAD~2 >/dev/null 2>&1 > git bisect bisect run echo --log 2>&1 | grep running > >> Is this expected? In https://bugzilla.redhat.com/show_bug.cgi?id=2139883 Todd suggested it might be related to >> >> d1bbbe45df (bisect--helper: reimplement `bisect_run` shell function in C, 2021-09-13) >> >> but I haven't tried it myself. > > Yes, it bisects to that commit. +cc Christian, who mentored this gsoc > project. > > I think the problem is that we are now feeding the arguments to > parse_options() in git bisect--helper, and it doesn't realize that it > needs to stop after seeing that we are in "run" mode. And because > "--log" is an option to git-bisect--helper (it is the opposite of > "--no-log"), it is consumed there. > > As you noticed, the "--" stops parsing, so the one between "arg3" and > "arg4" is preserved. > > It feels like the invocation of bisect--helper ought to be passing "--" > itself to indicate the end of options, like: Normally you'd be righ, but there's a much easier way to do it in this case: cherry-pick https://lore.kernel.org/git/05262b6a7d1b20a0d2f2ca2090be284ffb8c679c.1661885419.git.gitgitgadget@xxxxxxxxx/ I.e. we're eating "--log" in particular, but could just stop understanding that option. I'll submit alternate fixes for this soon, I've been poking at various "bisect" behavior changes, and the commit that rewrote "run" introduced a few other regressions....
