Least Significant Bit

You love git bisect to traverse your history running scripts and find where your code got broken, right? But then you find bisect is not aware of submodules don’t sweat it’s git in the end, you have the power.

The problem

Let’s say that since last time you checked in a feature some commits where pushed that turned to break your code. You normally do it like this:

# you start the bug hunting
$ git bisect start

# mark HEAD commit as bad
$ git bisect bad

# mark a commit as good
$ git bisect good 6bb8524ed4c0ea201cb5b3ed3a66d7076dc60e12
Bisecting: 62 revisions left to test after this (roughly 6 steps)
[6bb8524ed4c0ea201cb5b3ed3a66d7076dc60e12] commit message of the good commit

# run a test against all commits
$ git bisect run cucumber features/awesome.feature:66

The good news is that cucumber complies with bisect run requirements: Note that the script (my_script in the above example) should exit with code 0 if the current source code is good, and exit with a code between 1 and 127 (inclusive), except 125, if the current source code is bad.

But between the good and bad commit your submodules can differ, and bisect is not aware of that at the moment. Well, no one force you to run the test directly, it says clearly a script so let’s script this.

The solution: a script

#sc script
# we update the submodules for each commit, so we run against correct code base
git submodule update
cucumber features/awesome.feature:66

Then do it executable chmod a+x sc, then run it:

$ git bisect run ./sc
# you end up with something like:
when running : cucumber features/awesome.feature:66
01bbc3ddc83678f3ff62b6495aca7450bfe0931a is the first bad commit
commit 01bbc3ddc83678f3ff62b6495aca7450bfe0931a
Author: some_author
Date:   Mon Apr 26 14:31:17 2010 +0200
    another commit message

I love working with great tools. Don’t forget in the end:

$ git bisect reset
$ git submodule update

now go kill that bug