Re: git bisect code 125 - "WFT?"

Jeff King [off-list ref] writes:

  2. If we do detect such a mishap, I'm not sure that "indeterminate
     result" is necessarily the best result, as that will just keep
     trying more and more commits without success. It is more likely a
     sign of a poorly written test script, and the best thing we could
     do is die and say "your test script looks buggy".

Exactly. I agree "Aborting the bisect as run-script is a crap" is the
right thing to do here.

Those codes are reserved by POSIX to indicate
"command not executable" and "command not found":
http://pubs.opengroup.org/onlinepubs/9699919799/utilities/V3_chap02.html#tag_18_08_02

Bisect used to treat them as codes returned by user
to mark a "bad" code.

With that approach it was not possible to differentiate
between codes returned by the user and codes returned by
shell (which is likely a sign of a poorly written test
script).

Another minor problem was lack of consistency in exit codes.
A "bad" code was marked by any value in range 1-124,126-127
and the gap in the middle looked weird.

Change the meaning of exit codes 126 and 127 to
"abort the bisect process" to fixes the above problems.

Signed-off-by: Piotr Krukowiecki <redacted>
---
 git-bisect.sh |    4 ++--
 1 files changed, 2 insertions(+), 2 deletions(-)

W dniu 17.03.2011 18:56, Junio C Hamano pisze:

Jeff King [off-list ref] writes:

quoted

  2. If we do detect such a mishap, I'm not sure that "indeterminate
     result" is necessarily the best result, as that will just keep
     trying more and more commits without success. It is more likely a
     sign of a poorly written test script, and the best thing we could
     do is die and say "your test script looks buggy".

Exactly. I agree "Aborting the bisect as run-script is a crap" is the
right thing to do here.

Here's a patch. Next one changes git-bisect.txt

There's also Documentation/git-bisect-lk2009.txt which talks about exit
codes and should be changed somehow. As I understand it's a quote from an
email so I don't know if it should be edited in place, or should a note
be added at beginning?


(And again my patch has commit message longer than the changes...
 Now I understand why in-code documentation is lacking - after writing
 lengthy commit message documenting the code is just too much ;) )

diff --git a/git-bisect.sh b/git-bisect.sh
index c21e33c..9ca4852 100755
--- a/git-bisect.sh
+++ b/git-bisect.sh

@@ -376,9 +376,9 @@ bisect_run () {
       res=$?
 
       # Check for really bad run error.
-      if [ $res -lt 0 -o $res -ge 128 ]; then
+      if [ $res -lt 0 -o $res -ge 126 ]; then
 	  echo >&2 "bisect run failed:"
-	  echo >&2 "exit code $res from '$@' is < 0 or >= 128"
+	  echo >&2 "exit code $res from '$@' is < 0 or >= 126"
 	  exit $res
       fi
 

-- 
1.7.1

-- 
Piotr Krukowiecki

Update documentation after meaning of those exit codes changed
from "mark as bad code" to "abort bisect run".

Signed-off-by: Piotr Krukowiecki <redacted>
---
 Documentation/git-bisect.txt |   11 +++++------
 1 files changed, 5 insertions(+), 6 deletions(-)

diff --git a/Documentation/git-bisect.txt b/Documentation/git-bisect.txt
index a1e47d6..70d8807 100644
--- a/Documentation/git-bisect.txt
+++ b/Documentation/git-bisect.txt

@@ -232,17 +232,16 @@ $ 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.
+code between 1 and 124 (inclusive) if the current source code is bad.
+
+Exit code 125 should be used when the current source code cannot be
+tested. If the script exits with this code, the current revision will
+be skipped (see `git bisect skip` above).
 
 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".
 
-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
-revision will be skipped (see `git bisect skip` above).
-
 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
 header file, or "revision that does not have this commit needs this

-- 
1.7.1

-- 
Piotr Krukowiecki