You can not select more than 25 topics
Topics must start with a letter or number, can include dashes ('-') and can be up to 35 characters long.
100 lines
2.7 KiB
100 lines
2.7 KiB
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 |
|
|
|
|