Finding breaking commits with git bisect

Situation

A user reports "This minimal example which can just be tested as is does not compile with current Haxe. It used to compile with version x."

Approach

We can use git bisect to find the breaking commit. This works by marking revisions as either good or bad and recursing into the appropriate sub range. Git handles this quite nicely on its own, but care has to be taken when submodules are involved.

Strategy

First we have to start bisecting:

git bisect start

Since we know that things are currently broken, we can mark the revision as bad:

git bisect bad

At this point git doesn't have any "good" revision, so we have to find one. Since our user said it used to work in version x, we can check out the specific tag. For example:

git checkout tags/v3-00
git submodule update

Note that I sneaked the submodule update command in there, which is generally a good idea. With this we can rebuild the Haxe compiler in a separate shell window. Since I'm a windows user, I'm doing this:

make -f Makefile.win MSVC=1 clean
make -F Makefile.win MSVC=1

Obviously you could make a small batch/script file for this as you'll be running it a few time.

Now we should verify that the user example indeed works by compiling/running it, depending on the concrete issue. If it works as advertised, we can tell git about it:

git bisect good

Git now automatically checks out a revision between the good and the bad revision. We can update submodules again:

git submodule update

And build the Haxe compiler again:

make -f Makefile.win MSVC=1 clean
make -F Makefile.win MSVC=1

We check the user code to see if it works now. If it does, we mark the revision as good, otherwise we mark it as bad. Now we only have to repeat this process until the breaking commit has been found.

With that done, we should clean up:

git bisect reset
git submodule update