Answer by Schwern for Why does `git bisect skip` cause it to fail to find the proper revision sometimes?

git bisect uses a binary search algorithm to efficiently find the commit which broke the build. However, having commits which won't build at all breaks that.

Consider if your commits are like so...

1P - 2P - 3B - 4P - 5P - 6B - 7B - 8F - 9F

P for "Pass", B for "Broken", and F for "Fail". Broken commits are simply broken. Failing commits are failing because of a bug. In this case, 8F caused the bug.

If you tell git bisect that 1P is good and 9F is bad, bisect picks a commit between the known newest Good commit (1P) and the known oldest Bad commit (9F).

1P -- 2P - 3B - 4P - 5P - 6B - 7B - 8F - 9FG                                        B<------------------------------>

Perhaps 4P. That builds and passes, so it marks that as Good.

1P -- 2P - 3B - 4P - 5P - 6B - 7B - 8F - 9FG               G                        B<--------------->

Bisect assumes everything from 4P is good. It picks from 5P to 8F. Maybe 6B. That is a broken commit, so it is bad.

1P -- 2P - 3B - 4P - 5P - 6B - 7B - 8F - 9FG               G         B              B

Now it picks between 4P and 6B. Only 5P remains. It marks it as Good.

1P -- 2P - 3B - 4P - 5P - 6B - 7B - 8F - 9FG               G    G    B              B

git bisect stops and says 6B is the problem, but it was really 8F.

One thing is that some commits we have are auto-generated and don't need to make builds so we can't easily test those.

You'll either have to manually use git bisect skip, or create a script which can tell the difference between an unbuildable commit (the script should exit with 125) and a failing commit and use git bisect run.

Also consider changing your development process so it doesn't involve broken commits. That will save a lot of hassle.