]> git.ipfire.org Git - thirdparty/git.git/commit
bisect: output state before we are ready to compute bisection
authorChris Down <chris@chrisdown.name>
Wed, 11 May 2022 18:00:09 +0000 (19:00 +0100)
committerJunio C Hamano <gitster@pobox.com>
Wed, 11 May 2022 19:35:11 +0000 (12:35 -0700)
commit0cf1defa5a6764b8a0fd956ff4d114cb014cb8a4
tree11953eea824bd1de1eae50f0b0d5e8fc29264441
parente54793a95afeea1e10de1e5ad7eab914e7416250
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 <chris@chrisdown.name>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
bisect.h
builtin/bisect--helper.c
t/t6030-bisect-porcelain.sh