During the last month I have been switching between translating the IDE to Greek, and refining LC 6.7 and 7.0 releases, in terms of fixing bugs. Some bugs are quite easy to fix. Some others though, can be quite tricky. The first thing to do is locate where the bug comes from, and the next step is to actually fix it. In some cases, tracking down the cause of the bug is not that obvious. However, if you can find a previous version of the code where the bug was not present, then you can use some Git tools to find the specific commit in the history which introduced the bug. You could try to check out each commit, build it, and check if the bug is present or not. Usually there are a large number of commits, so this can take a really long time. This is a linear search. Hopefully, we can do much better by doing a binary search. Â This is where the git bisect command comes in.
What is git bisect?
Git bisect is an extremely useful command in the Git version control system. The bisect command does a binary search through your commit history to help you identify which commit introduced an issue. It is quite quick. Imagine that between a working version of the code and a buggy one, there are a few hundreds commits, say N. Using git bisect requires only log(N) steps!
How to use it?
1. You start by specifying two states, a bad and a good one. A state can be a commit hash, a branch name, or a tag name:
In this example, HEAD is the current revision (ie the bad one), and 6.7.0-dp-6 is a tag of a good revision.
2. We then test it for the presence of the bug. We inform Git if the bug is there by running git bisect good, or git bisect bad:
3. Repeating the same process bring us closer to the faulty commit:
4. If we ever arrive at a commit that won’t build for a known or irrelevant reason, or if we just don’t know if the specific revision is good or bad, then we simply run git bisect skip. It doesn’t define it as good or bad, picks a neighbor commit and moves on:
5. Voilà ! We fould the commit that introduced the bug!
After finding the problematic commit, we can see the diffs in github, and find out the cause of the bug.
6. We then move back to the HEAD (git bisect reset) and fix the bug!
3 comments
Join the conversationPeter - December 17, 2014
Other things that are neat:
* Writing test scripts to automate testing, so you can run a very big bisect overnight or while making a cup of tea (using `git bisect run’)
* Using `git bisect visualize’ to see which commits are still possible culprits — this is really useful because sometimes it helps you quickly eliminate whole branches
LiveCode - December 17, 2014
LiveBlog – What is git bisect you ask? Panos explains! http://t.co/AIklh1g1ip
James - January 10, 2015
While working or trying to build a xojo code app I have run and run into the same problem and can’t seem not to wonder that is it the program or myself. I know the doing the same thing over and over again is a form of insanity, what would you suggest?