July 8th, 2019 - 3 min read
Bisect is a git feature that lets you narrow down a problem. It's an advanced feature that's probably rarely used. Let's explain this by an example:
You've noticed a bug on head of master which is difficult to debug and you can't find the problem. In my current case, the production binary throws an error and I can't find the cause.
So with bisect, you can narrow it down to find the commit that introduced the problem.
You start the bisect by calling
git bisect start. Next, run your app and check if the bug is present if it is you call
git bisect bad.
Now we need to check out a version where we know that it's without the problem e.g. the last released version
git checkout v0.11.16 and test if the issue is not present.
If the version is working you can call
git bisect good - you could also do that directly without a previous check-out with
git bisect good v0.11.16 but if you don't know the good version then you can test it.
This will tell Git that we'd like to look between these two for good & bad versions and after the command above Git will log something like:
Bisecting: 28 revisions left to test after this (roughly 5 steps) [63eb8584e7520288332d515a5f13c11e40a70116] Hide markdown lint settings when markdown lint is disabled
So there are 28 revisions between the bad and the good version. Git also checked out the next version for us so we can check that revision and it's also indicating that we're probably done after 5 steps in my case.
Repeat the process until there is nothing left to bisect and don't stop too early as it's likely that you're getting versions without the problem. It's a bit cumbersome to do but it will help in the end.
Then after the last good/bad bisect, Git will output the first bad commit that probably introduced the problem.
In my case, it is the commit with hash
b6212f4b and the message
Update dependency & change to React-router v5. So I have to check if the issue is related to this version upgrade.
You can also review the decisions good/bad with
git log as there are
refs/bisect/(bad|good) visible at each commit that was marked during bisection.
To stop bisecting you can call
git bisect reset. This will reset your working copy to the state that you had before bisect.
There are probably more commands and you can look them up here but now you should know what you can do with it.
Unfortunately, I still have to do more debugging. It seems a bit like it's a version incompatibility but I need to check.
Here is probably a related issue with the same error message "Cannot read property 'apply' of undefined".
The bisect command is handy if you're working with many collaborators on a project and you know a version that was working perfectly. Then you can find the commit that introduced the issue.