diff options
Diffstat (limited to 'Documentation/git-bisect-script.txt')
| -rw-r--r-- | Documentation/git-bisect-script.txt | 90 |
1 files changed, 0 insertions, 90 deletions
diff --git a/Documentation/git-bisect-script.txt b/Documentation/git-bisect-script.txt deleted file mode 100644 index b4531c6e6a..0000000000 --- a/Documentation/git-bisect-script.txt +++ /dev/null @@ -1,90 +0,0 @@ -git-bisect-script(1) -==================== - -NAME ----- -git-bisect-script - 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 - - -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`. - - -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 - |