| blob | 0efd5d22610d92826cc0c7d75f098370db8c4451 |
4 <head>
9 /* Debug borders */
11 /*
12 border: 1px solid red;
13 */
14 }
16 body {
18 }
20 a {
23 }
26 }
28 em {
31 }
33 strong {
36 }
38 tt {
40 }
48 }
52 }
53 h2 {
55 }
56 h3 {
58 }
59 h3 + * {
61 }
66 }
68 hr {
70 }
72 p {
75 }
79 }
81 pre {
84 }
86 span#author {
91 }
92 span#email {
93 }
96 }
98 div#footer {
104 }
105 div#footer-text {
108 }
109 div#footer-badges {
112 }
114 div#preamble {
117 }
123 }
129 }
133 }
135 /* Block element titles. */
143 }
146 }
150 }
153 }
156 }
162 }
168 }
176 }
181 }
185 }
189 }
190 /* DEPRECATED: Pre version 8.2.7 verse style literal block. */
193 }
202 }
206 }
211 }
217 dl {
220 }
221 dt {
226 }
229 }
233 }
236 }
239 }
242 }
245 }
248 }
255 }
259 }
263 }
264 tfoot {
266 }
269 }
272 }
273 /* Because the table frame attribute is overriden by CSS in most browsers. */
276 }
280 }
284 }
290 }
293 }
296 }
302 }
305 }
309 }
313 }
317 }
321 }
326 }
330 }
340 }
345 }
347 div#toc {
349 }
351 div#toctitle {
358 }
363 }
367 }
371 }
375 }
376 /* Overrides for manpage documents */
377 h1 {
382 }
383 h2 {
385 }
388 }
392 }
394 /* Workarounds for IE6's broken and incomplete CSS2. */
400 }
407 }
413 }
418 }
422 }
426 }
431 }
433 /* IE6 sets dynamically generated links as visited. */
435 </style>
437 /*<![CDATA[*/
441 /////////////////////////////////////////////////////////////////////
442 // Table Of Contents generator
443 /////////////////////////////////////////////////////////////////////
445 /* Author: Mihai Bazon, September 2002
446 * http://students.infoiasi.ro/~mishoo
447 *
448 * Table Of Content generator
449 * Version: 0.4
450 *
451 * Feel free to use this script under the terms of the GNU General Public
452 * License, as long as you do not remove or alter this notice.
453 */
455 /* modified by Troy D. Hanson, September 2006. License: GPL */
456 /* modified by Stuart Rackham, 2006, 2009. License: GPL */
458 // toclevels = 1..4.
468 }
470 }
476 }
481 // Function that scans the DOM tree for header elements (the DOM2
482 // nodeIterator API would be a better technique but not supported by all
483 // browsers).
490 }
492 }
493 }
494 }
497 }
512 }
515 },
518 /////////////////////////////////////////////////////////////////////
519 // Footnotes generator
520 /////////////////////////////////////////////////////////////////////
522 /* Based on footnote generation code from:
523 * http://www.brandspankingnew.net/archive/2005/07/format_footnote.html
524 */
534 n++;
535 // Use [\s\S] in place of . so multi-line matches work.
536 // Because JavaScript has no s (dotall) regex flag.
547 }
548 }
552 // Process footnoterefs.
561 }
562 }
563 }
564 }
566 }
567 /*]]>*/
568 </script>
569 </head>
570 <body>
572 <h1>
573 git-bisect(1) Manual Page
574 </h1>
577 <p>git-bisect -
578 Find by binary search the change that introduced a bug
579 </p>
580 </div>
581 </div>
588 </div></div>
589 </div>
592 <div class="paragraph"><p>The command takes various subcommands, and different options depending
593 on the subcommand:</p></div>
596 <pre><tt>git bisect help
602 git bisect visualize
604 git bisect log
606 </div></div>
608 binary search process to find which change introduced a bug, given an
613 <h3 id="_basic_bisect_commands_start_bad_good">Basic bisect commands: start, bad, good</h3><div style="clear:left"></div>
615 command is as follows:</p></div>
618 <pre><tt>$ git bisect start
619 $ git bisect bad # Current version is bad
621 # tested that was good</tt></pre>
622 </div></div>
624 command bisects the revision tree and outputs something similar to
625 the following:</p></div>
629 </div></div>
631 You would now compile that kernel and boot it. If the booted kernel
632 works correctly, you would then issue the following command:</p></div>
636 </div></div>
637 <div class="paragraph"><p>The output of this command would be something similar to the following:</p></div>
641 </div></div>
643 depending on whether it is good or bad issuing the command "git bisect good"
649 the original HEAD, issue the following command:</p></div>
653 </div></div>
656 that, as it cleans up the old bisection state.)</p></div>
658 instead:</p></div>
662 </div></div>
663 <div class="paragraph"><p>For example, <tt>git bisect reset HEAD</tt> will leave you on the current
664 bisection commit and avoid switching commits at all, while <tt>git bisect
667 <div class="paragraph"><p>To see the currently remaining suspects in <em>gitk</em>, issue the following
668 command during the bisection process:</p></div>
672 </div></div>
673 <div class="paragraph"><p><tt>view</tt> may also be used as a synonym for <tt>visualize</tt>.</p></div>
674 <div class="paragraph"><p>If the <em>DISPLAY</em> environment variable is not set, <em>git log</em> is used
680 </div></div>
681 <h3 id="_bisect_log_and_bisect_replay">Bisect log and bisect replay</h3><div style="clear:left"></div>
683 command to show what has been done so far:</p></div>
687 </div></div>
689 revision, you can save the output of this command to a file, edit it to
690 remove the incorrect entries, and then issue the following commands to
691 return to a corrected state:</p></div>
694 <pre><tt>$ git bisect reset
695 $ git bisect replay that-file</tt></pre>
696 </div></div>
697 <h3 id="_avoiding_testing_a_commit">Avoiding testing a commit</h3><div style="clear:left"></div>
698 <div class="paragraph"><p>If, in the middle of a bisect session, you know that the next suggested
699 revision is not a good one to test (e.g. the change the commit
700 introduces is known not to work in your environment and you know it
701 does not have anything to do with the bug you are chasing), you may
702 want to find a nearby commit and try that instead.</p></div>
706 <pre><tt>$ git bisect good/bad # previous round was good or bad.
707 Bisecting: 337 revisions left to test after this
708 $ git bisect visualize # oops, that is uninteresting.
710 # was suggested</tt></pre>
711 </div></div>
713 the revision as good or bad in the usual manner.</p></div>
716 to do it for you by issuing the command:</p></div>
720 </div></div>
722 a bad commit and one or more skipped commits.</p></div>
728 </div></div>
729 <div class="paragraph"><p>This tells the bisect process that no commit after <tt>v2.5</tt>, up to and
732 would issue the command:</p></div>
736 </div></div>
737 <div class="paragraph"><p>This tells the bisect process that the commits between <tt>v2.5</tt> included
739 <h3 id="_cutting_down_bisection_by_giving_more_parameters_to_bisect_start">Cutting down bisection by giving more parameters to bisect start</h3><div style="clear:left"></div>
740 <div class="paragraph"><p>You can further cut down the number of trials, if you know what part of
741 the tree is involved in the problem you are tracking down, by specifying
746 </div></div>
748 bisect space down by specifying all of the good commits immediately after
753 # v2.6.20-rc6 is bad
755 </div></div>
758 or bad, you can bisect by issuing the command:</p></div>
762 </div></div>
764 exit with code 0 if the current source code is good, and exit with a
766 source code is bad.</p></div>
771 cannot be tested. If the script exits with this code, the current
774 are used by POSIX shells to signal specific error status (127 is for
775 command not found, 126 is for command found but not executable---these
776 details do not matter, as they are normal errors in the script, as far as
780 header file, or "revision that does not have this commit needs this
781 patch applied to work around another problem this bisection is not
783 <div class="paragraph"><p>To cope with such a situation, after the inner <em>git bisect</em> finds the
784 next revision to test, the script can apply the patch
785 before compiling, run the real test, and afterwards decide if the
786 revision (possibly with the needed patch) passed the test and then
787 rewind the tree to the pristine state. Finally the script should exit
788 with the status of the real test to let the "git bisect run" command loop
789 determine the eventual outcome of the bisect session.</p></div>
790 </div>
795 --no-checkout
796 </dt>
797 <dd>
798 <div class="paragraph"><p>Do not checkout the new working tree at each iteration of the bisection
800 it point to the commit that should be tested.</p></div>
801 <div class="paragraph"><p>This option may be useful when the test you would perform in each step
802 does not require a checked out tree.</p></div>
803 <div class="paragraph"><p>If the repository is bare, <tt>--no-checkout</tt> is assumed.</p></div>
804 </dd>
805 </dl></div>
806 </div>
810 <li>
811 <p>
812 Automatically bisect a broken build between v1.2 and HEAD:
813 </p>
816 <pre><tt>$ git bisect start HEAD v1.2 -- # HEAD is bad, v1.2 is good
818 </div></div>
819 </li>
820 <li>
821 <p>
822 Automatically bisect a test failure between origin and HEAD:
823 </p>
826 <pre><tt>$ git bisect start HEAD origin -- # HEAD is bad, origin is good
828 </div></div>
829 </li>
830 <li>
831 <p>
832 Automatically bisect a broken test case:
833 </p>
836 <pre><tt>$ cat ~/test.sh
837 #!/bin/sh
838 make || exit 125 # this skips broken builds
839 ~/check_test_case.sh # does the test case pass?
841 $ git bisect run ~/test.sh</tt></pre>
842 </div></div>
844 fails, we skip the current commit.
848 outside the repository to prevent interactions between the bisect,
849 make and test processes and the scripts.</p></div>
850 </li>
851 <li>
852 <p>
853 Automatically bisect with temporary modifications (hot-fix):
854 </p>
857 <pre><tt>$ cat ~/test.sh
858 #!/bin/sh
860 # tweak the working tree by merging the hot-fix branch
861 # and then attempt a build
862 if git merge --no-commit hot-fix &&
863 make
864 then
865 # run project specific test and report its status
866 ~/check_test_case.sh
867 status=$?
868 else
869 # tell the caller this is untestable
870 status=125
871 fi
873 # undo the tweak to allow clean flipping to the next commit
874 git reset --hard
876 # return control
877 exit $status</tt></pre>
878 </div></div>
879 <div class="paragraph"><p>This applies modifications from a hot-fix branch before each test run,
880 e.g. in case your build or test environment changed so that older
881 revisions may need a fix which newer ones have already. (Make sure the
882 hot-fix branch is based off a commit which is contained in all revisions
883 which you are bisecting, so that the merge does not pull in too much, or
885 </li>
886 <li>
887 <p>
888 Automatically bisect a broken test case:
889 </p>
894 </div></div>
896 on a single line.</p></div>
897 </li>
898 <li>
899 <p>
900 Locate a good region of the object graph in a damaged repository
901 </p>
904 <pre><tt>$ git bisect start HEAD <known-good-commit> [ <boundary-commit> ... ] --no-checkout
905 $ git bisect run sh -c '
909 rc=$?
910 rm -f tmp.$$
912 </div></div>
913 <div class="paragraph"><p>In this case, when <em>git bisect run</em> finishes, bisect/bad will refer to a commit that
914 has at least one parent whose reachable graph is fully traversable in the sense
916 </li>
917 </ul></div>
918 </div>
921 <div class="paragraph"><p><a href="git-bisect-lk2009.html">Fighting regressions with git bisect</a>,
923 </div>
927 </div>
928 </div>
933 </div>
934 </div>
935 </body>
936 </html>