The Good, the Bad and the Bisect

Lately I had an issue with my Kirby installation. The custom panel fields, introduced by a plugin, threw an error. I was sure that they worked before, but couldn't find the error by myself. Fortunately, I remembered that git has feature to find a commit which introduced a bug by using binary search: git bisect.

Since Kirby is all file based, it's easy to check out older commits and test if the panel worked at that point of the git history. And this is exactly how git bisect works.

To start the search for the commit which introduced a bug, you have open your terminal and check out a version from the git history which worked. To list all commits you can use the log command. I prefer the shorter --oneline output.

Copy the hash of a commit before the bug was introduced. And (optionally) one afterwards.

Now you have to tell git, that the search can begin.

Afterwards git wants to know which commit was a “good“ one and which was “bad“. Instead of the commit hashes you can also use tags. If you omit the hash or tag for the bad one, git uses the latest commit.

Git responds with the amount of revisions between these commits and roughly estimates how many steps will be necessary to find the “bad“ one.

Git also checks out a commit in the middle. Now you have to check your project and if the bug is still present you have to tell git that the situation is still bad by using this command:

But if the bug is gone you have to use:

You have to repeat this game until the commit you were looking for was found. In the end, git will present you the commit with all the corresponding files which can now be analysed. If you keep your commits organized with a good commit message and without committing a hundred unrelated files at once there is a good chance to find the bug.

Finally, you have to stop the bisect mode with:

That's it.

• git bisect