4

I'm experiencing a problem with the mainline Linux kernel and I want to find the commit which introduced the bug with git-bisect to notify the author that his change introduced a bug.

I spotted a good and a bad commit and started the bisection. Good commits are the ones those don't have the bug yet, bad commits are the ones where the bug is already introduced. The most recent pull of Linus' tree still has the bug, so I assume there is no fix for the bug yet, so this is why I think it's important to notify the author.

However, as I progressed with the bisection and proceeded to test all commits along the way (there were no skipped commits with „git bisect skip”, all of them were evaluated as being good or bad), at one point git surprised me with the following message:

The merge base 7089db84e356562f8ba737c29e472cc42d530dbc is bad.
This means the bug has been fixed between 7089db84e356562f8ba737c29e472cc42d530dbc and [02c3de1105228e367320e7fdeffbf511904f398c 6d04dfc8966019b8b0977b2cb942351f13d2b178 7aa7d608112baf63a0b1278955f9619427373807].

Git doesn't allow me to progress from this point. I don't understand this. I know that different branches are often merged (especially in Linus' tree), and the bug is likely introduced in a side branch, but even if that's the case, I think I should be able to identify the commit which introduced the bug, even if that's a merge commit. And how come that the bug has been fixed between the listed commits while I still have the problem when I build from the latest commit?

MegaBrutal
  • 310
  • 2
  • 9

2 Answers2

3

This is answered in-depth in a documentation file in the Git source tree. Essentially, Git is telling you that according to your test case, the code on your own branch is wrong and it inherited that wrongness from before some feature-branch split off. The bug was then fixed in the feature-branch. Meanwhile:

And how come that the bug has been fixed between the listed commits while I still have the problem when I build from the latest commit?

There are two obvious reasons this might be the case:

  1. The feature branch with the fix is not part of the latest commit.
  2. The bug might have been fixed, then re-introduced.

Case 2 is probably more likely here, and the fix could be as simple—or complicated—as "we thought this other feature W was ready, then we decided it wasn't and reverted it in the feature/X branch, then we put it back because now it was ready"—and it's feature/W itself causes the bug, so that the bug goes away in the feature/X commit-span during which feature/W is reverted-away.

(In some cases, a bug is accidentally fixed and then equally accidentally re-introduced. This is common in algorithms that have some unstable property that nobody thinks matters, that actually turns out to matter. For instance, some sort algorithms are not stable—do not preserve the order of "equal" items in the list-of-items being sorted—and others are. If all the sort keys are unique, the stability of the sort is irrelevant. If your bug is tied to non-unique sort keys, then perhaps the actual bug is either that the sort is not stable, or that the key itself is wrong and the bug is not what you think it is.)

torek
  • 448,244
  • 59
  • 642
  • 775
0

I just had the same message. Wanted to bisect an already fixed issue. I changed from

git bisect good/bad

to

git bisect new/old

which pointed me to the bug fixing commit.

HolgerJeromin
  • 2,201
  • 20
  • 21