Git bisect and reversing a mistaken patch

2011/12/09: Updated links

Using version control software such as git is like slicing the bread of programming. It lets you deal with changes in small chunks instead of having to troubleshoot everything at the same time. This comes in really handy when you’re trying to isolate a problem. If you can tell which change broke your system, then you can review just those changes and look for ways to fix them.

For example, some views I’d created in Drupal 6 had mysteriously vanished from the web interface. Fortunately, I’d exported them to code using Features, so I knew I could get them back. I needed to find out which change removed them so that I could make sure I didn’t accidentally undo the other relevant changes.

git bisect to the rescue! The idea behind git bisect is the same one behind the marvelous efficiencies of binary search: test something in the middle of what you’re looking at. If it’s good, take the later half and test the middle. If it’s bad, take the earlier half and test the middle. It’s like what people do when guessing a number between 1 and 100. It makes sense to start at 50 and ask: is the number greater than 50? If it is, ask: is the number greater than 75? And so on. Handy trick, except sometimes it can be difficult to add or subtract in your head and figure out the next number you should ask.

git bisect does that adding-up for you. You start with git bisect start in the root of your source tree. You tell it if the current version is considered broken, using git bisect bad. You tell it the last known working version, with git bisect good changeset-identifier. Then it takes the middle of that range. Test it to see whether it works, and type in git bisect good or git bisect bad depending on what you get. It’ll present you with another changeset, and another, until it can identify the first changeset that fails. If you can automate the test, you can even use the git bisect run command to quickly identify the problem.

Now that you’ve identified the relevant changeset, you can use git show changeset-identifier to look at the changes. If you save it to a file, you can edit the diff and then use the patch command to reverse and apply the diff. Alternatively, you can undo or tweak your changes by hand.

The git bisect section in the free Git SCM book has more information, as does the manual page. Hope this helps!

  • Bread-slicing is a great analogy for version control! I have never used git bisect before. Thanks for the tip.

  • Dave Marquardt

    Mercurial has a very similar idea, very nice.

  • How does a programmer learn version control? If it’s not something that’s taught for a degree in computer science, then we need to learn on our own. How would an engineering company add version control into its culture and process flow? I wonder, if there’s a need for a workshop on the topic, maybe a professional organization such as IEEE or ACM can offer this topic. Where to start?

  • I learned it in the process of contributing to open source. =) Other people absorb it at work. I think it should be an essential part of application development if students learn that in school. They should get into the habit of checking their work into a repository, and that will also help teachers see their progress.

    As for introducing it into an existing team: you can start with one person who refuses to put up with the insanity and who version-controls his or her stuff, then move to a shared repository and more people using the process, and then let them indoctrinate new people.

  • I love the idea of git-bisect (and totally agree with the rant on students who should learn control version systems), but I think one might be able to automatize it by giving as a parameter a testing script which decides for you if the version checked out passes a given set of test or not?

    The link to seems broken, but I think all relevant information is available at

    Also, more generally, it seems that my configuration does not allow me to mail you nor comment on your site using Firefox 3.6.24, while it does when I use chromium-browser. Any idea what could cause this behavior?

  • Jeremy: Yup, you can totally automate git bisect, which is awesome. =D

    Thanks for updating the links!

    I have no idea what’s going on with that comment form, but will tinker around with it this weekend. Thank you for your patience!