diff options
Diffstat (limited to 'Documentation/git-bisect-script.txt')
| -rw-r--r-- | Documentation/git-bisect-script.txt | 62 |
1 files changed, 53 insertions, 9 deletions
diff --git a/Documentation/git-bisect-script.txt b/Documentation/git-bisect-script.txt index 1f5e38626..1b0345199 100644 --- a/Documentation/git-bisect-script.txt +++ b/Documentation/git-bisect-script.txt @@ -3,25 +3,69 @@ git-bisect-script(1) NAME ---- -git-bisect-script - Some git command not yet documented. +git-bisect-script - Find the change that introduced a bug SYNOPSIS -------- -'git-bisect-script' [ --option ] <args>... +'git bisect' start +'git bisect' bad <rev> +'git bisect' good <rev> +'git bisect' reset [<branch>] DESCRIPTION ----------- -Does something not yet documented. +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: -OPTIONS -------- ---option:: - Some option not yet documented. +------------------------------------------------ +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 +------------------------------------------------ -<args>...:: - Some argument not yet documented. +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). Author |