From 0cf1defa5a6764b8a0fd956ff4d114cb014cb8a4 Mon Sep 17 00:00:00 2001 From: Chris Down Date: Wed, 11 May 2022 19:00:09 +0100 Subject: bisect: output state before we are ready to compute bisection Commit 73c6de06aff8 ("bisect: don't use invalid oid as rev when starting") changes the behaviour of `git bisect` to consider invalid oids as pathspecs again, as in the old shell implementation. While that behaviour may be desirable, it can also cause confusion. For example, while bisecting in a particular repo I encountered this: $ git bisect start d93ff48803f0 v6.3 $ ...which led to me sitting for a few moments, wondering why there's no printout stating the first rev to check. It turns out that the tag was actually "6.3", not "v6.3", and thus the bisect was still silently started with only a bad rev, because d93ff48803f0 was a valid oid and "v6.3" was silently considered to be a pathspec. While this behaviour may be desirable, it can be confusing, especially with different repo conventions either using or not using "v" before release names, or when a branch name or tag is simply misspelled on the command line. In order to avoid situations like this, make it more clear what we're waiting for: $ git bisect start d93ff48803f0 v6.3 status: waiting for good commit(s), bad commit known We already have good output once the bisect process has begun in earnest, so we don't need to do anything more there. Signed-off-by: Chris Down Signed-off-by: Junio C Hamano --- t/t6030-bisect-porcelain.sh | 18 ++++++++++++++++++ 1 file changed, 18 insertions(+) (limited to 't') diff --git a/t/t6030-bisect-porcelain.sh b/t/t6030-bisect-porcelain.sh index 5382e5d216..686f6d5c7f 100755 --- a/t/t6030-bisect-porcelain.sh +++ b/t/t6030-bisect-porcelain.sh @@ -1025,4 +1025,22 @@ test_expect_success 'bisect visualize with a filename with dash and space' ' git bisect visualize -p -- "-hello 2" ' +test_expect_success 'bisect state output with multiple good commits' ' + git bisect reset && + git bisect start >output && + grep "waiting for both good and bad commits" output && + git bisect good "$HASH1" >output && + grep "waiting for bad commit, 1 good commit known" output && + git bisect good "$HASH2" >output && + grep "waiting for bad commit, 2 good commits known" output +' + +test_expect_success 'bisect state output with bad commit' ' + git bisect reset && + git bisect start >output && + grep "waiting for both good and bad commits" output && + git bisect bad "$HASH4" >output && + grep -F "waiting for good commit(s), bad commit known" output +' + test_done -- cgit v1.3