Description of problem: When running "git bisect run ./myscript --log arg" only "./myscript arg" is executed. Version-Release number of selected component (if applicable): git-2.38.1-1.fc36.x86_64 How reproducible: Always Steps to Reproduce: 1. git bisect start BAD GOOD 2. git bisect run ./myscript arg1 --log arg2 --log -- arg3 --log arg4 Actual results: running './myscript' 'arg1' 'arg2' '--' 'arg3' '--log' 'arg4' Expected results: running ./myscript arg1 --log arg2 --log -- arg3 --log arg4 Additional info: The expected output was gathered on RHEL9 using git-2.31.1-2.el9.2.x86_64
I tested: git-2.35.1-1.fc36.x86_64 - bad git-2.34.1-1.fc35.x86_64 - bad git-2.33.0-1.fc36.x86_64 - good git-2.32.0-1.fc36.2.x86_64 - good git-2.31.1-3.fc35.1.x86_64 - good
Thanks Lukáš. I would guess this is related to the conversion of git bisect run from shell to C which was released in 2.34.0. In particular, d1bbbe45df (bisect--helper: reimplement `bisect_run` shell function in C, 2021-09-13) stands out as a possible suspect. I'm not sure if this would be considered a bug or not by upstream. If you're able, I would suggest asking git.org (no subscription required). If it's not expected behavior, someone who knows the area well might provide a patch. I think you may be able to avoid this by using sh -c 'command' to call the run command: git bisect run sh -c './myscript arg1 --log arg2 --log -- arg3 --log arg4'
Thanks for posting that to the git list. I'm glad to see it's led to a lively discussion and several different patch series to fix things. The folks on the git list are fantastic! :) I'll keep any eye on that thread and see what gets merged. Then we can see whether we should apply it to 2.38.x or wait a bit for 2.39.0.
This was fixed in git-2.39.0, which was pushed to Fedora 36 a few weeks ago.