Documentation / git-bisect.txton commit GIT 0.99.9d (87ce294)
   1git-bisect(1)
   2=============
   3
   4NAME
   5----
   6git-bisect - Find the change that introduced a bug
   7
   8
   9SYNOPSIS
  10--------
  11'git bisect' start
  12'git bisect' bad <rev>
  13'git bisect' good <rev>
  14'git bisect' reset [<branch>]
  15'git bisect' visualize
  16'git bisect' replay <logfile>
  17'git bisect' log
  18
  19DESCRIPTION
  20-----------
  21This command uses 'git-rev-list --bisect' option to help drive
  22the binary search process to find which change introduced a bug,
  23given an old "good" commit object name and a later "bad" commit
  24object name.
  25
  26The way you use it is:
  27
  28------------------------------------------------
  29git bisect start
  30git bisect bad                  # Current version is bad
  31git bisect good v2.6.13-rc2     # v2.6.13-rc2 was the last version
  32                                # tested that was good
  33------------------------------------------------
  34
  35When you give at least one bad and one good versions, it will
  36bisect the revision tree and say something like:
  37
  38------------------------------------------------
  39Bisecting: 675 revisions left to test after this
  40------------------------------------------------
  41
  42and check out the state in the middle. Now, compile that kernel, and boot
  43it. Now, let's say that this booted kernel works fine, then just do
  44
  45------------------------------------------------
  46git bisect good                 # this one is good
  47------------------------------------------------
  48
  49which will now say
  50
  51------------------------------------------------
  52Bisecting: 337 revisions left to test after this
  53------------------------------------------------
  54
  55and you continue along, compiling that one, testing it, and depending on
  56whether it is good or bad, you say "git bisect good" or "git bisect bad",
  57and ask for the next bisection.
  58
  59Until you have no more left, and you'll have been left with the first bad
  60kernel rev in "refs/bisect/bad".
  61
  62Oh, and then after you want to reset to the original head, do a
  63
  64------------------------------------------------
  65git bisect reset
  66------------------------------------------------
  67
  68to get back to the master branch, instead of being in one of the bisection
  69branches ("git bisect start" will do that for you too, actually: it will
  70reset the bisection state, and before it does that it checks that you're
  71not using some old bisection branch).
  72
  73During the bisection process, you can say
  74
  75        git bisect visualize
  76
  77to see the currently remaining suspects in `gitk`.
  78
  79The good/bad input is logged, and `git bisect
  80log` shows what you have done so far.  You can truncate its
  81output somewhere and save it in a file, and run
  82
  83        git bisect replay that-file
  84
  85if you find later you made a mistake telling good/bad about a
  86revision.
  87
  88
  89Author
  90------
  91Written by Linus Torvalds <torvalds@osdl.org>
  92
  93Documentation
  94-------------
  95Documentation by Junio C Hamano and the git-list <git@vger.kernel.org>.
  96
  97GIT
  98---
  99Part of the gitlink:git[7] suite
 100