X-Git-Url: https://git.verplant.org/?a=blobdiff_plain;f=Documentation%2Fgit-bisect-script.txt;h=b4531c6e6abf9627799fd8f4bdb1371ca3aaf89c;hb=78938b0d8a95b09d94af214fdb6b5f053a5edb98;hp=1f5e38626b60f369d4c622c946008d2e7c82f50b;hpb=58eaf287f1b25f6427b06bd72d8e555615828aeb;p=git.git

diff --git a/Documentation/git-bisect-script.txt b/Documentation/git-bisect-script.txt
index 1f5e3862..b4531c6e 100644
--- a/Documentation/git-bisect-script.txt
+++ b/Documentation/git-bisect-script.txt
@@ -3,25 +3,77 @@ 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>]
+'git bisect' visualize
+
 
 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:
+
+------------------------------------------------
+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
 
-OPTIONS
--------
---option::
-	Some option not yet documented.
+	git bisect visualize
 
-<args>...::
-	Some argument not yet documented.
+to see the currently remaining suspects in `gitk`.
 
 
 Author