Code and documentation clean-up to "git bisect".
* ad/bisect-cleanup:
bisect: don't mix option parsing and non-trivial code
bisect: simplify the addition of new bisect terms
bisect: replace hardcoded "bad|good" by variables
Documentation/bisect: revise overall content
Documentation/bisect: move getting help section to the end
bisect: correction of typo
If, in the middle of a bisect session, you know that the next suggested
revision 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 nearby commit and try that instead.
If, in the middle of a bisect session, you know that the suggested
revision is not a good one to test (e.g. it fails to build and you
know that the failure does not have anything to do with the bug you
are chasing), you can manually select a nearby commit and test that
one instead.
For example:
------------
$ git bisect good/bad # previous round was good or bad.
Bisecting: 337 revisions left to test after this
Bisecting: 337 revisions left to test after this (roughly 9 steps)
$ git bisect visualize # oops, that is uninteresting.
$ git reset --hard HEAD~3 # try 3 revisions before what
# was suggested
@ -169,18 +176,19 @@ the revision as good or bad in the usual manner.
@@ -169,18 +176,19 @@ the revision as good or bad in the usual manner.
Bisect skip
~~~~~~~~~~~~
Instead of choosing by yourself a nearby commit, you can ask Git
to do it for you by issuing the command:
Instead of choosing a nearby commit by yourself, you can ask Git to do
it for you by issuing the command:
------------
$ git bisect skip # Current version cannot be tested
------------
But Git may eventually be unable to tell the first bad commit among
a bad commit and one or more skipped commits.
However, if you skip a commit adjacent to the one you are looking for,
Git will be unable to tell exactly which of those commits was the
first bad one.
You can even skip a range of commits, instead of just one commit,
using the "'<commit1>'..'<commit2>'" notation. For example:
You can also skip a range of commits, instead of just one commit,
using range notation. For example:
------------
$ git bisect skip v2.5..v2.6
@ -196,8 +204,8 @@ would issue the command:
@@ -196,8 +204,8 @@ would issue the command:
$ git bisect skip v2.5 v2.5..v2.6
------------
This tells the bisect process that the commits between `v2.5` included
and `v2.6` included should be skipped.
This tells the bisect process that the commits between `v2.5` and
`v2.6` (inclusive) should be skipped.
Cutting down bisection by giving more parameters to bisect start
@ -231,14 +239,14 @@ or bad, you can bisect by issuing the command:
@@ -231,14 +239,14 @@ or bad, you can bisect by issuing the command:
$ git bisect run my_script arguments
------------
Note that the script (`my_script` in the above example) should
exit with code 0 if the current source code is good, and exit with a
code between 1 and 127 (inclusive), except 125, if the current
source code is bad.
Note that the script (`my_script` in the above example) should exit
with code 0 if the current source code is good/old, and exit with a
code between 1 and 127 (inclusive), except 125, if the current source
code is bad/new.
Any other exit code will abort the bisect process. It should be noted
that a program that terminates via "exit(-1)" leaves $? = 255, (see the
exit(3) manual page), as the value is chopped with "& 0377".
that a program that terminates via `exit(-1)` leaves $? = 255, (see the
exit(3) manual page), as the value is chopped with `& 0377`.
The special exit code 125 should be used when the current source code
cannot be tested. If the script exits with this code, the current
@ -247,7 +255,7 @@ as the highest sensible value to use for this purpose, because 126 and 127
@@ -247,7 +255,7 @@ as the highest sensible value to use for this purpose, because 126 and 127
are used by POSIX shells to signal specific error status (127 is for
command not found, 126 is for command found but not executable---these
details do not matter, as they are normal errors in the script, as far as
"bisect run" is concerned).
`bisect run` is concerned).
You may often find that during a bisect session you want to have
temporary modifications (e.g. s/#define DEBUG 0/#define DEBUG 1/ in a
@ -260,7 +268,7 @@ next revision to test, the script can apply the patch
@@ -260,7 +268,7 @@ next revision to test, the script can apply the patch
before compiling, run the real test, and afterwards decide if the
revision (possibly with the needed patch) passed the test and then
rewind the tree to the pristine state. Finally the script should exit
with the status of the real test to let the "git bisect run" command loop
with the status of the real test to let the `git bisect run` command loop
determine the eventual outcome of the bisect session.
OPTIONS
@ -307,12 +315,12 @@ $ git bisect run ~/test.sh
@@ -307,12 +315,12 @@ $ git bisect run ~/test.sh
$ git bisect reset # quit the bisect session
------------
+
Here we use a "test.sh" custom script. In this script, if "make"
Here we use a `test.sh` custom script. In this script, if `make`
fails, we skip the current commit.
"check_test_case.sh" should "exit 0" if the test case passes,
and "exit 1" otherwise.
`check_test_case.sh` should `exit 0` if the test case passes,
and `exit 1` otherwise.
+
It is safer if both "test.sh" and "check_test_case.sh" are
It is safer if both `test.sh` and `check_test_case.sh` are
outside the repository to prevent interactions between the bisect,
make and test processes and the scripts.
@ -379,6 +387,11 @@ In this case, when 'git bisect run' finishes, bisect/bad will refer to a commit
@@ -379,6 +387,11 @@ In this case, when 'git bisect run' finishes, bisect/bad will refer to a commit
has at least one parent whose reachable graph is fully traversable in the sense
required by 'git pack objects'.
Getting help
~~~~~~~~~~~~
Use `git bisect` to get a short usage description, and `git bisect
help` or `git bisect -h` to get a long usage description.
* We use the convention that exiting with an exit code 10 means that
* the bisection process finished successfully.
@ -905,6 +950,7 @@ int bisect_next_all(const char *prefix, int no_checkout)
@@ -905,6 +950,7 @@ int bisect_next_all(const char *prefix, int no_checkout)
const unsigned char *bisect_rev;
char bisect_rev_hex[GIT_SHA1_HEXSZ + 1];
read_bisect_terms(&term_bad, &term_good);
if (read_bisect_refs())
die("reading bisect refs failed");
@ -926,8 +972,10 @@ int bisect_next_all(const char *prefix, int no_checkout)
@@ -926,8 +972,10 @@ int bisect_next_all(const char *prefix, int no_checkout)
*/
exit_if_skipped_commits(tried, NULL);
printf("%s was both good and bad\n",
oid_to_hex(current_bad_oid));
printf("%s was both %s and %s\n",
oid_to_hex(current_bad_oid),
term_good,
term_bad);
exit(1);
}
@ -942,7 +990,8 @@ int bisect_next_all(const char *prefix, int no_checkout)
@@ -942,7 +990,8 @@ int bisect_next_all(const char *prefix, int no_checkout)
if (!hashcmp(bisect_rev, current_bad_oid->hash)) {
exit_if_skipped_commits(tried, current_bad_oid);
printf("%s is the first bad commit\n", bisect_rev_hex);
printf("%s is the first %s commit\n", bisect_rev_hex,