.\" It was generated using the DocBook XSL Stylesheets (version 1.69.1).
.\" Instead of manually editing it, you probably should edit the DocBook XML
.\" source for it and then use the DocBook XSL Stylesheets to regenerate it.
-.TH "GIT\-AM" "1" "02/12/2007" "" ""
+.TH "GIT\-AM" "1" "03/23/2007" "" ""
.\" disable hyphenation
.nh
.\" disable justification (adjust text to left margin only)
This flag is passed to the git\-apply program that applies the patch.
.TP
\-C<n>, \-p<n>
-These flag are passed to the git\-apply program that applies the patch.
+These flags are passed to the git\-apply program that applies the patch.
.TP
\-\-interactive
Run interactively, just like git\-applymbox.
.\" It was generated using the DocBook XSL Stylesheets (version 1.69.1).
.\" Instead of manually editing it, you probably should edit the DocBook XML
.\" source for it and then use the DocBook XSL Stylesheets to regenerate it.
-.TH "GIT\-BISECT" "1" "01/19/2007" "" ""
+.TH "GIT\-BISECT" "1" "03/23/2007" "" ""
.\" disable hyphenation
.nh
.\" disable justification (adjust text to left margin only)
git bisect visualize
git bisect replay <logfile>
git bisect log
+git bisect run <cmd>...
.fi
This command uses \fIgit\-rev\-list \-\-bisect\fR 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.
.nf
$ git bisect start arch/i386 include/asm\-i386
.fi
+If you have a script that can tell if the current source code is good or bad, you can automatically bisect using:
+.sp
+.nf
+$ git bisect run my_script
+.fi
+Note that the "run" script (my_script in the above example) should exit with code 0 in case the current source code is good and with a code between 1 and 127 (included) in case the current source code is bad.
+
+Any other exit code (a program that does "exit(\-1)" leaves $? = 255, see exit(3) manual page, the value is chopped with "& 0377") will abort the automatic bisect process.
+
+You may often find that during bisect you want to have near\-constant tweaks (e.g., s/#define DEBUG 0/#define DEBUG 1/ in a header file, or "revision that does not have this commit needs this patch applied to work around other problem this bisection is not interested in") applied to the revision being tested.
+
+To cope with such a situation, after the inner git\-bisect finds the next revision to test, with the "run" script, you can apply that tweak before compiling, run the real test, and after the test decides if the revision (possibly with the needed tweaks) passed the test, rewind the tree to the pristine state. Finally the "run" script can exit with the status of the real test to let "git bisect run" command loop to know the outcome.
.SH "AUTHOR"
Written by Linus Torvalds <torvalds@osdl.org>
.SH "DOCUMENTATION"
.\" It was generated using the DocBook XSL Stylesheets (version 1.69.1).
.\" Instead of manually editing it, you probably should edit the DocBook XML
.\" source for it and then use the DocBook XSL Stylesheets to regenerate it.
-.TH "GIT" "7" "03/19/2007" "" ""
+.TH "GIT" "7" "03/23/2007" "" ""
.\" disable hyphenation
.nh
.\" disable justification (adjust text to left margin only)