CODEWITHSUNDEEP
gitgit-bisectbisect
MichaelGofron
MichaelGofron

Reputation: 1400

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

I'm investigating creating a tool to enable us to bisect commits quickly. 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. My thinking had been to have the tooling skip those commits with git bisect skip. I had read, for instance, that bisect uses a pseudo random number generator to determine which commit to try after skipping a commit. I'd also seen that it seems to fail if a large percentage of your commits fail to build as per this site. Any ideas why?

Upvotes: 0

Views: 53

Answers (1)

Schwern
Schwern

Reputation: 164829

git bisect uses a binary search algorithm to efficiently find the commit which broke the build. It doesn't give any details about that algorithm.

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 - 9F
G                                        B
      <------------------------------>

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

1P -- 2P - 3B - 4P - 5P - 6B - 7B - 8F - 9F
G               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 - 9F
G               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 - 9F
G               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 have some options.

Manually tell Git which commit to test next using git reset --hard. See Avoiding testing a commit.

Manually use git bisect skip to tell Git to skip the commit and pick a different one. However...

...if you skip a commit adjacent to the one you are looking for, Git will be unable to tell exactly which of those commits was the first bad one.

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. This is probably the best option as you should be automating this process anyway.

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

Upvotes: 1

Related Questions