Archive for January, 2010

Git bisect

January 25, 2010

KDE is supposed to move over to git and there has been lots of discussion and blog posts about that lately. Now it is on me to provide a small post myself. Those that know git bisect can skip this one.

Git bisect is a great tool that saved my day several times already and again just today, shortly before the release of KDE 4.4 SC. In short git bisect is there to find faulty commits.

Often when developing you encounter bugs where you know that it worked many revisions ago, but how do you find the revision that introduced the bug? When using git a few commands are enough:

  1. start it: git bisect start
  2. tell git which version is bad: git bisect bad {sha1/tag}?
  3. tell git which version is good: git bisect good {sha1/tag}?
  4. end it: git bisect reset

Basically that is all you need to know and here is an example session (I was at master):

  1. git bisect start
  2. git bisect bad //latest commit is bad
  3. git bisect good 73ea4b2fd5ae39993009dd765c6ff562ceec09da//this commit is good
  4. XY revisions left to test after this (roughly Z steps)
  5. recompiling
  6. testing
  7. either git bisect bad or git bisect good depending if it did not work or if it did work
  8. go to 4 or 9
  9. d4f650537917441fcfd3aa71e0c646b8fc7464ec is the first bad commit//yeah it was me who did crap 😉
  10. git reset
  11. Fix and commit

That process is very fast as git uses bisecting as the name suggests e.g. there are 100 commits, 1 is working 100 not, now it checks commit 50, if it works it is checking commit 75 otherwise commit 25 …

Whee and another really stupid and bad bug that was only triggered ocassionally bites the dust.

Baseline? Using git bisect when a commit is wrong or even better use test-cases to avoid wrong commits in the first place.