Bisection visualization hint..

Bisection visualization hint..

[Linus Torvalds]

I'm testing bisection to find a bug that causes my G5 to no longer boot, 
and during the process have found this command line very nice:

	gitk bisect/bad --not $(cd .git/refs ; ls bisect/good-*)

it basically shows the state of bisection with the known bad commit as the 
top, and cutting off all the good commits - so what you see are the 
potential buggy commits.

But it's not the nicest of command lines and depends on knowing how
bisection works, so maybe we could make

	git bisect visualize

do this for us?

		Linus

Re: Bisection visualization hint..

[Junio C Hamano]

Linus Torvalds <torvalds@osdl.org> writes:

> I'm testing bisection to find a bug that causes my G5 to no longer boot, 
> and during the process have found this command line very nice:
>
> 	gitk bisect/bad --not $(cd .git/refs ; ls bisect/good-*)
>
> it basically shows the state of bisection with the known bad commit as the 
> top, and cutting off all the good commits - so what you see are the 
> potential buggy commits.

> But it's not the nicest of command lines and depends on knowing how
> bisection works, so maybe we could make
>
> 	git bisect visualize
>
> do this for us?

Will do.

Another thing that might make sense is roll it also into gitk, a
new command from "File" menu to cause it to re-read not just ref
values but the rev-list itself out of that particular rev-list
command (and add any other common patterns as we discover them).

Re: Bisection visualization hint..

[A Large Angry SCM]

Junio C Hamano wrote:
> Linus Torvalds <torvalds@osdl.org> writes:
> 
>>I'm testing bisection to find a bug that causes my G5 to no longer boot, 
>>and during the process have found this command line very nice:
>>
>>	gitk bisect/bad --not $(cd .git/refs ; ls bisect/good-*)
>>
>>it basically shows the state of bisection with the known bad commit as the 
>>top, and cutting off all the good commits - so what you see are the 
>>potential buggy commits.
> 
>>But it's not the nicest of command lines and depends on knowing how
>>bisection works, so maybe we could make
>>
>>	git bisect visualize
>>
>>do this for us?
> 
> Will do.
> 
> Another thing that might make sense is roll it also into gitk, a
> new command from "File" menu to cause it to re-read not just ref
> values but the rev-list itself out of that particular rev-list
> command (and add any other common patterns as we discover them).

Unless gitk will always be part of git, this is better off as a gitk 
feature or gitk helper script. IE. it belongs in the gitk namespace, not 
the git namespace.

That said, a wrapper for "git show-branch" (git show-bisect?) would be 
nice also.

Fix bisection terminating condition

[Linus Torvalds]

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 <torvalds@osdl.org>
---
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

Re: Bisection visualization hint..

[Linus Torvalds]

On Tue, 30 Aug 2005, A Large Angry SCM wrote:
> 
> Unless gitk will always be part of git, this is better off as a gitk 
> feature or gitk helper script. IE. it belongs in the gitk namespace, not 
> the git namespace.

I really think that gitk is pretty fundamental. If for no other reason 
than the big fact that it helps people understand what is going on. That's 
why it's mentioned in the tutorial - people who have only used something 
broken like CVS will have a hard time visualizing what's going on, I 
suspect, but with gitk it all looks simple.

		Linus

[PATCH] 'git bisect visualize'

[Junio C Hamano]

Linus says:

    I'm testing bisection to find a bug that causes my G5 to no longer boot,
    and during the process have found this command line very nice:

	    gitk bisect/bad --not $(cd .git/refs ; ls bisect/good-*)

    it basically shows the state of bisection with the known bad commit as the
    top, and cutting off all the good commits - so what you see are the
    potential buggy commits.

Signed-off-by: Junio C Hamano <junkio@cox.net>

---

 * I think turning the flow inside out and driving bisect from
   gitk might make more sense, though.  You start 'Bisect...'
   from the 'File' menu, click on one node and say 'good' or
   'bad' from its pop-up menu,...

 git-bisect-script |   33 ++++++++++++++++++++++++++-------
 1 files changed, 26 insertions(+), 7 deletions(-)

0e0713a470e7bea760aa0bd7510ddc668fb8b744
diff --git a/git-bisect-script b/git-bisect-script
--- a/git-bisect-script
+++ b/git-bisect-script
@@ -2,12 +2,13 @@
 . git-sh-setup-script || dir "Not a git archive"
 
 usage() {
-    echo >&2 'usage: git bisect [start | bad | good | next | reset]
+    echo >&2 'usage: git bisect [start|bad|good|next|reset|visualize]
 git bisect start		reset bisect state and start bisection.
 git bisect bad [<rev>]		mark <rev> a known-bad revision.
 git bisect good [<rev>...]	mark <rev>... known-good revisions.
 git bisect next			find next bisection to test and check it out.
-git bisect reset [<branch>]	finish bisection search and go back to branch.'
+git bisect reset [<branch>]	finish bisection search and go back to branch.
+git bisect visualize		show the current state in gitk.'
     exit 1
 }
 
@@ -57,9 +58,15 @@ bisect_start() {
 
 bisect_bad() {
 	bisect_autostart
-        case "$#" in 0 | 1) ;; *) usage ;; esac
-	rev=$(git-rev-parse --verify --default HEAD "$@") || exit
-	echo "$rev" > "$GIT_DIR/refs/bisect/bad"
+        case "$#" in
+	0)
+		rev=$(git-rev-parse --verify HEAD) ;;
+	1)
+		rev=$(git-rev-parse --verify "$1") ;;
+	*)
+		usage ;;
+	esac || exit
+	echo "$rev" >"$GIT_DIR/refs/bisect/bad"
 	bisect_auto_next
 }
 
@@ -67,10 +74,12 @@ bisect_good() {
 	bisect_autostart
         case "$#" in
 	0)    revs=$(git-rev-parse --verify HEAD) || exit ;;
-	*)    revs=$(git-rev-parse --revs-only --no-flags "$@") || exit ;;
+	*)    revs=$(git-rev-parse --revs-only --no-flags "$@") &&
+	      test '' != "$revs" || die "Bad rev: $@" ;;
 	esac
 	for rev in $revs
 	do
+	    rev=$(git-rev-parse --verify $rev) || exit
 	    echo "$rev" >"$GIT_DIR/refs/bisect/good-$rev"
 	done
 	bisect_auto_next
@@ -107,8 +116,11 @@ bisect_next() {
 	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 [ "$rev" = "" ]; then
+		die "Your input does not make sense."
+	    fi
 	    echo "$rev is first bad commit"
-	    git-diff-tree --pretty $rev
+	    git-diff-tree --pretty "$rev"
 	    exit 0
 	fi
 	echo "Bisecting: $nr revisions left to test after this"
@@ -118,6 +130,11 @@ bisect_next() {
 	ln -sf refs/heads/bisect "$GIT_DIR/HEAD"
 }
 
+bisect_visualize() {
+	bisect_next_check fail
+	gitk bisect/bad --not `cd "$GIT_DIR/refs" && echo bisect/good-*`
+}
+
 bisect_reset() {
 	case "$#" in
 	0) branch=master ;;
@@ -150,6 +167,8 @@ case "$#" in
     next)
         # Not sure we want "next" at the UI level anymore.
         bisect_next "$@" ;;
+    visualize)
+        bisect_visualize "$@" ;;
     reset)
         bisect_reset "$@" ;;
     *)

Re: Fix bisection terminating condition

[Junio C Hamano]

Linus Torvalds <torvalds@osdl.org> writes:

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

Thanks.