When testing bisection and using gitk to visualize the result, it was 
obvious that the termination condition was broken.

We know what the bad entry is only when the bisection ends up telling us 
to test the known-bad entry again.

Also, add a safety net: if somebody marks as good something that includes 
the known-bad point, we now notice and complain, instead of writing an 
empty revision to the new bisection branch.

Signed-off-by: Linus Torvalds <[EMAIL PROTECTED]>
---
diff --git a/git-bisect-script b/git-bisect-script
--- a/git-bisect-script
+++ b/git-bisect-script
@@ -105,12 +105,16 @@ bisect_next() {
        good=$(git-rev-parse --sq --revs-only --not \
                $(cd "$GIT_DIR" && ls refs/bisect/good-*)) &&
        rev=$(eval "git-rev-list --bisect $good $bad") || exit
-       nr=$(eval "git-rev-list $rev $good" | wc -l) || exit
-       if [ "$nr" -le "1" ]; then
+       if [ -z "$rev" ]; then
+           echo "$bad was both good and bad"
+           exit 1
+       fi
+       if [ "$rev" = "$bad" ]; then
            echo "$rev is first bad commit"
            git-diff-tree --pretty $rev
            exit 0
        fi
+       nr=$(eval "git-rev-list $rev $good" | wc -l) || exit
        echo "Bisecting: $nr revisions left to test after this"
        echo "$rev" > "$GIT_DIR/refs/heads/new-bisect"
        git checkout new-bisect || exit
-
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Reply via email to