Re: Git bisect does not find commit introducing the bug

From: Stephan Beyer <s-beyer@gmx.net>
Date: Feb 17, 2017, 23:21 UTC
Message-ID: <d4991e4b-cbc4-da14-381a-88704e457a19@gmx.net>
In-Reply-To: <CAMX8fZWe2HO78ySonHX0adtPUxVPbj5_vo-NUGrjwpb7gPdGrQ@mail.gmail.com>

Hi,

On 02/17/2017 11:29 PM, Alex Hoffman wrote:

> According to the documentation "git bisect" is designed "to find the
> commit that introduced a bug" .
> I have found a situation in which it does not returns the commit I expected.
> In order to reproduce the problem:

For the others who are too lazy to clone your repo and run the scripts, the history is like that (read from bottom to top) and I marked the commit found by git bisect and the on you expected:

*   7a9e952 (bisect bad) <BAD>
|\
| *   671cec2 <BAD> <--- expected
| |\
| * | 04c6f4b <BAD> <--- found
* | |   3915157 <GOOD>
|\ \ \
| | |/
| |/|
| * | f4154e9 (bisect good) <GOOD>
| * | 85855bf <BAD>
| |/
* | f1a36f5 <BAD>
|/
* 1b7fb88 <BAD>

The <BAD> and <GOOD> markers are set by your definition of what good and what bad commits are.

> First of all this is confusing, as this commit cannot be reached
> starting from "v.good".

Hm, IMHO it shows that your example is pretty artificial (although you might have come across it in a real-world scenario): you introduced a new feature in f4154e9 (and it worked) and you broke that feature by making the merge 671cec2. However, the feature (that broke in 671cec2) did not even exist in 04c6f4b; so a test on the feature would not fail (leading to "bisect bad" as in the example), it would not exist (leading to "bisect skip").

And if we are not talking about passing or failing tests but about crashing, bisect finds the right thing: f4154e9 was not crashing, but 04c6f4b is crashing. Yes, it's not the commit that introduced the crash (which would be the first commit in the repo) but it's the first crashing commit after the one marked as good.

So I'd consider this a feature or rather correct behavior, not a bug.

In other words: bisect assumes that your repo is usually in a good state and you have a commit that changes it to a bad state. In your case you have a repo that is in a bad state and you have a commit that switches it to a good state and later you merge a bad-state branch and you have a bad state again. It is not made for that use-case, I think.

Cheers
  Stephan