X-Git-Url: https://git.octo.it/?a=blobdiff_plain;f=Documentation%2Fgit-bisect.txt;h=ac4b4965a93fd5087896e8e807f6ad28db566df7;hb=HEAD;hp=b124b0751c195db82a49d0bcf434da429ec71019;hpb=dbc37438687e110697574d175e4eca5f9cbeae81;p=git.git diff --git a/Documentation/git-bisect.txt b/Documentation/git-bisect.txt index b124b075..ac4b4965 100644 --- a/Documentation/git-bisect.txt +++ b/Documentation/git-bisect.txt @@ -8,16 +8,21 @@ git-bisect - Find the change that introduced a bug SYNOPSIS -------- -'git bisect' start -'git bisect' bad -'git bisect' good -'git bisect' reset [] -'git bisect' visualize -'git bisect' replay -'git bisect' log +'git bisect' DESCRIPTION ----------- +The command takes various subcommands, and different options +depending on the subcommand: + + git bisect start [...] + git bisect bad + git bisect good + git bisect reset [] + git bisect visualize + git bisect replay + git bisect log + 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 @@ -26,10 +31,10 @@ 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 +$ 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 @@ -43,7 +48,7 @@ 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 +$ git bisect good # this one is good ------------------------------------------------ which will now say @@ -62,7 +67,7 @@ kernel rev in "refs/bisect/bad". Oh, and then after you want to reset to the original head, do a ------------------------------------------------ -git bisect reset +$ git bisect reset ------------------------------------------------ to get back to the master branch, instead of being in one of the bisection @@ -72,26 +77,57 @@ not using some old bisection branch). During the bisection process, you can say - git bisect visualize +------------ +$ git bisect visualize +------------ to see the currently remaining suspects in `gitk`. -The good/bad you told the command is logged, and `git bisect +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 +------------ +$ git bisect replay that-file +------------ if you find later you made a mistake telling good/bad about a revision. +If in a middle of bisect session, you know what the bisect +suggested to try next is not a good one to test (e.g. the change +the commit introduces is known not to work in your environment +and you know it does not have anything to do with the bug you +are chasing), you may want to find a near-by commit and try that +instead. It goes something like this: + +------------ +$ git bisect good/bad # previous round was good/bad. +Bisecting: 337 revisions left to test after this +$ git bisect visualize # oops, that is uninteresting. +$ git reset --hard HEAD~3 # try 3 revs before what + # was suggested +------------ + +Then compile and test the one you chose to try. After that, +tell bisect what the result was as usual. + +You can further cut down the number of trials if you know what +part of the tree is involved in the problem you are tracking +down, by giving paths parameters when you say `bisect start`, +like this: + +------------ +$ git bisect start arch/i386 include/asm-i386 +------------ + Author ------ Written by Linus Torvalds Documentation --------------- +------------- Documentation by Junio C Hamano and the git-list . GIT