git bisect doesn't return any output

Question

I tried to use git bisect lately, but it just didn't work. The tree remained in master and I saw no output from git bisect whatsoever. Here's what I've tried:

git bisect start
git bisect bad   # no output, tried a couple of times
git bisect good  # no output
git bisect reset #-> Already on 'master'

I tried this on two different repos. Didn't work. git --version is 1.6.3.3 on Ubuntu 9.10 Any ideas?

Nealy

What arguments are you passing to good and bad? Is the "bad" commit a descendant of the "good" commit? – Kling

I'm having the same issue. No output after doing git bisect start and then either git bisect bad or git bisect good. git bisect visualize outputs You need to give me at least one good and one bad revision. (You can use "git bisect bad" and "git bisect good" for that.) no matter how many times I do git bisect good or git bisect bad – Underpants

Answer 1

Introduction to Git Bisect

"git bisect" can be a little confusing at first. Once you understand what it does, it'll be easy.

The typical scenerio for "git bisect" is: A bug was just discovered. You want to find out which rev introduced the bug. You know the bug exists in the latest rev, but it was introduced in a prior rev. You will need a way to find out whether or not the bug exists. This can be an automatic test, or it can be a test you run by hand.

Let's get started. Starting from the latest rev in your branch, issue:

git bisect start

And then tell git that the current version is known to be bad:

git bisect bad

Now we need to find a good rev. Check one something old enough to not have the bug. If you think that 32 revs ago ought to be good, then:

git checkout HEAD~32

And run your test to see if it has the bug. If it has the bug, you'll need to try an even older rev (just issue "git checkout HEAD~32" again). As soon as you land on a rev that does not have the bug, then:

git bisect good

That tells git that the current version is good. Git will immediately check out a rev in-between the good rev and the bad rev; you'll see output, for example:

$ git bisect good
Bisecting: 7 revisions left to test after this (roughly 3 steps)
[909ba8cd7698720d00b2d10738f6d970a8955be4] Added convenience delegators to Cache

Run your test, and depending upon the results of the test, issue one of these commands:

• git bisect good # the test passed
• git bisect bad # the test failed
• git bisect skip # we can't run the test on this rev for some reason (doesn't compile, etc.)

Git will continue to change to different revs, and you'll keep telling it good, bad or skip. When git finally figures out which rev started all the trouble, you'll get something like this:

b25ab3cee963f4738264c9c9b5a8d1a344a94623 is the first bad commit
commit b25ab3cee963f4738264c9c9b5a8d1a344a94623
Author: Wayne Conrad <[email protected]>
Date:   Fri Dec 25 18:20:54 2009 -0700

    More tests and refactoring

:040000 040000 6ff7502d5828598af55c7517fd9626ba019b16aa 39f346cb5a289cdb0955fcbba552f40e704b7e65 M      routecalc

And your current rev will be there, on the first bad commit.

Running git bisect "hands off"

If your test is automatic, then you can let git do all the work. Do everything you did to get started above:

git bisect start
git bisect bad
git checkout HEAD~32    # or however far back it takes to find a good rev
git bisect good

And now for the magic. All you need is a test program that returns exit code "0" for success and 1 (for example) for failure. Tell git about your test:

git bisect run tests/mytest.rb

Git will now run the test, using the results to automatically do a "git bisect good" or a "git bisect bad." It will continue doing that until the commit that introduced the bug is found. All you have to do is sit back and watch.

When you're done

When you're done, issue:

git bisect reset

Git will put you back where you started.

Stroman

git bisect run will continue running until the commit that introduces the bug is found. Not until the first bad rev. – Shaw

@Lorenz, I meant first in order of commit, not first checked by bisect. I admit the wording is ambiguous--good catch. I'll update it. – Stroman

This is an introduction to how git bisect works and not the answer to the problem. The problem is that git bisect is not working properly despite using it as the general instructions describe. It's a good introduction though. – Underpants

@the_minted Thanks for the compliment. I think this answer does address the OPs problem; the question did not show the OP using "git checkout" to change HEAD before doing "git bisect good" or "git bisect bad", as shown in this answer. – Stroman

You're right - using git checkout HEAD~N after git bisect start solves the issue. Another way to do this to specify the commit boundaries in the start statement like this git start HEAD HEAD~N. Unfortunately my negative vote has locked in, so I wasn't able to withdraw it. – Underpants

@the_minted No worries. Until I figure out where to redeem these points for a toaster or something, it's not important how many of them I have. – Stroman

Answer 2

What you tried failed because you told it that the same treeish was both good and bad. which obviously doesn't make any sense

git bisect start # tells git you want to do a bisect operation
git bisect bad # tells git the current treesh (HEAD) is bad
git bisect good # tells git the current treeish (HEAD) is good

Because a given treeish can't possibly be good AND bad git just assumes you were correcting yourself.

The key here is that if you don't specify a treeish git assumes you mean the current one.

A better way to have done this would be to first find the treeish of a commit where things work. then...

git bisect start
git bisect bad # tells it HEAD is bad
git bisect good abc123 # treeish of the good commit

after that bisect will start running automatically. You'll still have to interact with it and tell it the state of the bisected commits though (or write a script to automate it).

Simmonds