| git-bisect(1) |
| ============= |
| |
| NAME |
| ---- |
| git-bisect - Find the change that introduced a bug |
| |
| |
| SYNOPSIS |
| -------- |
| 'git bisect' start |
| 'git bisect' bad <rev> |
| 'git bisect' good <rev> |
| 'git bisect' reset [<branch>] |
| 'git bisect' visualize |
| 'git bisect' replay <logfile> |
| 'git bisect' log |
| |
| DESCRIPTION |
| ----------- |
| This command uses 'git-rev-list --bisect' option to help drive |
| the binary search process to find which change introduced a bug, |
| given an old "good" commit object name and a later "bad" commit |
| object name. |
| |
| The way you use it is: |
| |
| ------------------------------------------------ |
| git bisect start |
| git bisect bad # Current version is bad |
| git bisect good v2.6.13-rc2 # v2.6.13-rc2 was the last version |
| # tested that was good |
| ------------------------------------------------ |
| |
| When you give at least one bad and one good versions, it will |
| bisect the revision tree and say something like: |
| |
| ------------------------------------------------ |
| Bisecting: 675 revisions left to test after this |
| ------------------------------------------------ |
| |
| and check out the state in the middle. Now, compile that kernel, and boot |
| it. Now, let's say that this booted kernel works fine, then just do |
| |
| ------------------------------------------------ |
| git bisect good # this one is good |
| ------------------------------------------------ |
| |
| which will now say |
| |
| ------------------------------------------------ |
| Bisecting: 337 revisions left to test after this |
| ------------------------------------------------ |
| |
| and you continue along, compiling that one, testing it, and depending on |
| whether it is good or bad, you say "git bisect good" or "git bisect bad", |
| and ask for the next bisection. |
| |
| Until you have no more left, and you'll have been left with the first bad |
| kernel rev in "refs/bisect/bad". |
| |
| Oh, and then after you want to reset to the original head, do a |
| |
| ------------------------------------------------ |
| git bisect reset |
| ------------------------------------------------ |
| |
| to get back to the master branch, instead of being in one of the bisection |
| branches ("git bisect start" will do that for you too, actually: it will |
| reset the bisection state, and before it does that it checks that you're |
| not using some old bisection branch). |
| |
| During the bisection process, you can say |
| |
| git bisect visualize |
| |
| to see the currently remaining suspects in `gitk`. |
| |
| The good/bad input is logged, and `git bisect |
| log` shows what you have done so far. You can truncate its |
| output somewhere and save it in a file, and run |
| |
| git bisect replay that-file |
| |
| if you find later you made a mistake telling good/bad about a |
| revision. |
| |
| |
| Author |
| ------ |
| Written by Linus Torvalds <torvalds@osdl.org> |
| |
| Documentation |
| ------------- |
| Documentation by Junio C Hamano and the git-list <git@vger.kernel.org>. |
| |
| GIT |
| --- |
| Part of the gitlink:git[7] suite |
| |
