"Johannes Schindelin via GitGitGadget" <gitgitgadget@xxxxxxxxx> writes: > From: Johannes Schindelin <johannes.schindelin@xxxxxx> > > We do not want `git bisect --bogus-option` to start a bisection. To > verify that, we look for the tell-tale error message `You need to start > by "git bisect start"` and fail if it was found. > > Signed-off-by: Johannes Schindelin <johannes.schindelin@xxxxxx> > --- Sorry, but this looks unclear to me. In the test "--bisect-terms" is used, and from "git grep" it does seem to be one of the valid options "git bisect--helper" can take. It is unclear if the patch wanted to literally use "--bogus-option" insteaed of it but used "--bisect-terms" by mistake, or if that valid option is "bogus" only in the sense that the option is not yet relevant immediately after "git bisect reset" before a new "git bisect start" session has begun. IOW, "bogus" both in the patch title and the test title needs to be clarified. To put it another way, can we demonstrate the same correctness by seeing "git bisect --no-such-option" fail immediately after "git bisect reset"? > t/t6030-bisect-porcelain.sh | 10 ++++++++++ > 1 file changed, 10 insertions(+) > > diff --git a/t/t6030-bisect-porcelain.sh b/t/t6030-bisect-porcelain.sh > index 83931d482fb..6d6e72276ae 100755 > --- a/t/t6030-bisect-porcelain.sh > +++ b/t/t6030-bisect-porcelain.sh > @@ -900,6 +900,16 @@ test_expect_success 'bisect start with one term1 and term2' ' > git bisect reset > ' > > +test_expect_success 'bogus command does not start bisect' ' > + git bisect reset && > + test_must_fail git bisect --bisect-terms 1 2 2>out && > + ! grep "You need to start" out && > + test_must_fail git bisect --bisect-terms 2>out && > + ! grep "You need to start" out && > + grep "git bisect.*visualize" out && > + git bisect reset > +' > + > test_expect_success 'bisect replay with term1 and term2' ' > git bisect replay log_to_replay.txt >bisect_result && > grep "$HASH2 is the first term1 commit" bisect_result &&
