4

I'm on a separate branch titled redesign-test-fixes and I run git bisect start. After that, I test my bug and run git bisect bad. Terminal prints no output. I then run git bisect good. Same thing, no output is printed on terminal. It's as if bisect is not running to begin with. Normally I expect terminal to output info about the number of steps left. What's wrong and how can I fix this? Am I in some git state that is not allowing me to run bisect.

The git status responds with:

On branch redesign-test-fixes
nothing to commit, working directory clean

However, if I run git bisect start the git status responds with:

On branch redesign-test-fixes
You are currently bisecting, started from branch 'redesign-test-fixes'.
  (use "git bisect reset" to get back to the original branch)

nothing to commit, working directory clean
thank_you
  • 11,001
  • 19
  • 101
  • 185

1 Answers1

11

You are using git bisect incorrectly. After typing git bisect start, you need to provide a range of commits for git bisect to use. This range is defined by a "good" commit, in which you are certain the bug does not appear, followed by a "bad" commit, where you believe the bug is certain to be present. Hence your usage should start off like this:

git bisect start
git bisect good <SHA-1 of good commit>
git bisect bad  <SHA-1 of bad commit>

Assuming you had 20 commits in between the bad and the good, you should then see output looking something like this:

Bisecting: 10 revisions left to test after this (roughly 4 steps)

The reason there are 10 revisions left is because Git has already checked out the middle commit in your chosen range, and it knows that there are at most 10 commits which need to be examined to find the commit where the bug was introduced.

Next, you need to inspect your application at this middle commit and determine whether or not the bug is present. If you don't find the bug, then type:

git bisect good

and if you do see the bug then type:

git bisect bad

This will again show you output looking like this:

Bisecting: 5 revisions left to test after this (roughly 2 steps)

Without explicitly telling you, Git has again checked out the middle commit of the new range.

You will continue this process of typing git bisect good/bad, and when there is nothing left to bisect, Git will show you the first bad commit:

a8h39dk32... is the first bad commit

Further reading:

Here is a link to a great tutorial which covers the full usage of git bisect. And I found that even the official Git documentation is not completely thorough.

Tim Biegeleisen
  • 502,043
  • 27
  • 286
  • 360
  • 1
    So I have to manually find a commit that was good to start the bisect? Couldn't `git bisect` simply go to the halfway point in the commits and work from there instead of providing it a SHA-1 of a good and bad commit? Can't the default of a bad commit be my most recent commit? I always thought git bisect didn't need SHA-1 commits to begin. – thank_you Aug 18 '16 at 15:58
  • 2
    What does the "halfway point in the commits" even mean? Would it really be good design for Git to choose the halfway point between your latest commit and the first commit even made, even if that first commit were made years ago? Yes, you need to provide a _range_ (initial good and bad commit) of commits to use `git bisect`. – Tim Biegeleisen Aug 18 '16 at 16:02
  • 1
    @jason328 Yes, the documentation is poor in this regard, because you left thinking usage was a certain way, when it is really not this way. Try my answer and let me know if you still have any problems. – Tim Biegeleisen Aug 18 '16 at 16:03