Git bisect

I thought it might be informative to show a bit on how I pinpoint an offending commit to the repository.
In this case, the issue was reported in the 170 beta, and confirmed working in the 1.2.169 version.

Since I’ve reviewed all code coming into 170, I did have suspicions around what might have changed recently.
But still, I wanted to know if the problem was in bob.jar/editor or the engine.
This is to split the problem domain into much smaller pieces, and at the same time rule out large chunks of code as the culprit.

I already had a 170 engine built locally, so I started with downloading bob.jar (169 and 170).
Building with either of those versions didn’t make any difference, so I knew the issue was in the 170 engine code.

Next, since I don’t remember all commit sha1’s by heart, and there are a few to sort through, I decided to do a git bisect.
It lets you do a divide and conquer on the commits.
It is really powerful, and it’s even scriptable.

In my case, the test was more easy to do using visual testing, and quick to test, so I didn’t need to script anything.

I started the bisect by telling it what version was bad (HEAD) and which version was good (in this case 4f76136f9. I could have written the tag 1.2.169 as well):

$ git bisect start
$ git bisect bad
$ git bisect good 4f76136f9
Bisecting: 69 revisions left to test after this (roughly 6 steps)
[eaff4acb1d38159d6fb9f6200770ec60b2704205] Merge branch 'dev' into issue-4803-emscripten-1-39

At this point, the repo has moved to a changelist (eaff4ac) in between the good and bad versions.
So now I build the engine. And run it.

The engine didn’t show the bug, so that version was good.
I tell git that:

$ git bisect good
Bisecting: 34 revisions left to test after this (roughly 5 steps)
[82252e5ad6d2148ef0695b7204b909a9d11ba0f9] #3181. Refacor handling 9 slice node with no texture.

I built once more, and discover that this version was bad:

$ git bisect bad
Bisecting: 13 revisions left to test after this (roughly 4 steps)
[1b89914d5119cd3b0d89bb48764fcc947872cd85] Merge pull request #4805 from defold/issue-4803-emscripten-1-39

After 5 iterations, I know exactly what changelist was the problem, and I can start debugging it.
It took me 5 builds * ~40 seconds, and including writing this post, I round it up to 10 minutes.


Thanks for sharing information about bisect, it’s look very comfortable to do stuff like this

I’ll never do it manually after that :smiley:


Yeah, it’s a huge time saver.
And the scriptability is also a great tool, e.g running a single test in a batch of unit test, to find the culprit. Or parse the output to check for certain keywords etc.


Oh yes! Good tip right here. Bisect saved me a lot of head scratching in a few instances, working on Interrogation and other projects as well.

1 Like