Find a needle in a haystack with git bisect
Since this bug doesn’t exist in release-5.7.0, I know that the bug was introduced sometime after that branch was created from main:
Out of curiosity, I wanted to know how many commits there were between when I know it was working and when I know it was broken:
Which tells me that I’ve narrowed it down to only… 2,088 commits! Obviously, it’s not practical to browse through 2,088 commits trying to guess which one might have caused the bug.
Fortunately, git bisect makes this way easier. I already have a “good” commit where things work, and a “bad” commit where they don’t:
git bisect now basically guides me through a binary search to find the commit that caused the bug. It’s helpfully started me out with this message:
Like a binary search, git bisect has checked out the commit right in the middle of the good and bad commits. Now I run my code, and see if the bug is still there. In this case, the bug wasn’t present, so I enter:
Using binary search logic, git bisect knows that the bug must have been introduced after the commit I just tested. So it tells me:
