On Sun, May 22 2022, Bagas Sanjaya wrote: > On 5/21/22 21:48, Johannes Schindelin via GitGitGadget wrote: >> * When a bogus command is provided, we now error out instead of trying to >> start a git bisect run. > > Ah! git bisect now behave like other shell commands where bogus > command is given, instead of "accidentally" start the bisection. > > BTW, do the current version of git bisect exhibit that accidental > behavior? No, this is a fix for a bug introduced in an earlier version of this topic, but the more general issue remains. See https://lore.kernel.org/git/220521.86zgjazuy4.gmgdl@xxxxxxxxxxxxxxxxxxx/ Rather than a surgical fix for a specific issue I noted, with the initial report being: https://lore.kernel.org/git/220223.86v8x56g7g.gmgdl@xxxxxxxxxxxxxxxxxxx/ This topic could really use some confidence building by adding new "git bisect" tests. I.e. let's have tests for what exit codes etc. we emit on various valid and invalid "git bisect" usage. We clearly don't have that since the proposed v2 would have introduced a regression, and this v3 would also have done that in other cases (while fixing the one specific case of "-h").
