|
|
|
|
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 you told the command 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 link:git.html[git] suite
|
|
|
|
|
|
