git bisect says Bisecting: a merge base must be tested

Question

I did a git bisect and got the result

Bisecting: a merge base must be tested
[bbdaf1111eea5365c0c94d6045d6263aab718925] Fix display bug with main-stage

How can I proceed?

Kaoliang

That's merely an informative message - if it didn't say this, and you were paying close attention to the count of expected tests to run, you might object that it's running a different number of tests than it said it had to. This message is telling you that the earlier approximations are about to be refined, based on whatever the result of this test is. – Workmanlike

Answer 1

This will happen if the given good and bad revision are not direct descendants of each other.

Let's assume a repository like this (using exemplary names for the commits):

* dffa2 good-commit
* b38f4 a2
* cc19f a1
| * d1f17 bad-commit
| * fbd1f b2
| * f66cc b1
|/
* 09f66 merge-base-commit

What "merge base" means

As the message uses the term "merge base", it might be helpful to understand that term to understand the message. A "merge base" of two or more commits is the latest commit which is a parent of all of those commits.

Therefore if those commits would be merged, all changes between the "merge base" and those commits will be merged together. Every commit which is a parent of "merge base" is not relevant to the merge, it already is a parent of all involved commits.

Understanding the bisect

The described message will happen in a case like this:

$ git bisect start
$ git bisect good good-commit
$ git bisect bad bad-commit
Bisecting: a merge base must be tested
[09f66] merge-base-commit

What bisecting does is to find the commit which introduced a problem (leading to a bad state), which in this case could lead to a problem:

Bug was not introduced between good-commit and bad-commit

Assume that the error existed in merge-base-commit. In this case it will not be possible to find the commit that introduced the bug in the difference between good-commit and bad-commit. Instead one of the commits a1, a2 and good-commit solves the problem, which is exactly what will happen if you decide the merge base to be bad:

$ git bisect bad
The merge base merge-base-commit is bad.
This means the bug has been fixed between 09f66 and [dffa2].

Problem was introduced between merge-base-commit and bad-commit

On the other hand if the merge base is good, the problem was introduced in b1, b2 or bad-commit. bisect will then continue between merge-base-commit and bad-commit, picking the commit in the middle between those commits and testing if that one is good:

$ git bisect good
Bisecting: 0 revisions left to test after this (roughly 1 step)
[fbd1f] b2

Bughouse

Answer 2

Let it run, it's normal if there are merges on the path that has to be bisected.

Beetroot

Answer 3

You just need to tell git bisect if this is a good commit or a bad commit - the "test" in question is you testing your code for the bug/feature you are trying to find.

You can do

git bisect good

or

git bisect bad

to continue.

Vig