Tag Archives: bugs

Tracking Down the Origin of a Bug

When something breaks, or you find a bug, it can be helpful to identify the commit which introduced the faulty code. Git comes with the ‘bisect’ command, which makes searching for that commit efficient.

Bisect helps automate a binary search through a series of commits, to find the earliest one which exhibits the problematic behaviour. After providing an initial ‘good’ commit without the bug, and a ‘bad’ commit which contains it, bisect will iteratively guess a commit and automatically check it out for you. After you test this checkout and identify if it is ‘good’ or ‘bad’, Git will guess the next commit, until it has identified the first ‘bad’ commit.

Here is an example of how to use bisect:

$ git bisect start
$ git bisect good [commit] # [commit] is the sha1/branch of a 'good' commit
$ git bisect bad  [commit] # [commit] is the sha1/branch of a 'bad' commit

Git will then checkout its guess, and output the commit information. You should then test the code, and indicate to Git if the commit contains the fault using:

$ git bisect good # OR
$ git bisect bad

After a number of iterations Git will output information on the offending commit, ex:

b047b02ea83310a70fd603dc8cd7a6cd13d15c04 is first bad commit
commit b047b02ea83310a70fd603dc8cd7a6cd13d15c04
Author: PJ Hyett
Date:   Tue Jan 27 14:48:32 2009 -0800

    secure this thing

:040000 040000 40ee3e7821b895e52c1695092db9bdc4c61d1730
f24d3c6ebcfc639b1a3814550e62d60b8e68a8e4 M  config

You should then run the following command to restore your repository to its state before you ran git bisect:

$ git bisect reset

This post is based off of the following:
http://book.git-scm.com/5_finding_issues_-_git_bisect.html
http://progit.org/book/ch6-5.html