[PATCH] Eliminate confusing "won't bisect on seeked tree" failure

[Carl Worth <cworth@cworth.org>]

This error message is very confusing---it doesn't tell the user
anything about how to fix the situation. And the actual fix
for the situation ("git bisect reset") does a checkout of a
potentially random branch, (compared to what the user wants to
be on for the bisect she is starting).

The simplest way to eliminate the confusion is to just make
"git bisect start" do the cleanup itself. There's no significant
loss of safety here since we already have a general safety in
the form of the reflog.

Signed-off-by: Carl Worth <cworth@cworth.org>
---
 On Thu, 21 Feb 2008 06:20:14 +0100, Mike Galbraith wrote:
 > I have no idea how tree became "seeked", but would love to know how to
 > "un-seek" it so I can proceed with a bisection.  Help?

 At first I thought this just needed a better error message, (the
 original "seeked tree" terminology came from cogito where there was a
 seek command). But then it occurred to me that the error should just
 be eliminated altogether. And that saves the tool having to explain
 something it can just do itself.

 git-bisect.sh |    3 +--
 1 files changed, 1 insertions(+), 2 deletions(-)

diff --git a/git-bisect.sh b/git-bisect.sh
index 74715ed..1e532bc 100755
--- a/git-bisect.sh
+++ b/git-bisect.sh
@@ -75,7 +75,6 @@ bisect_start() {
 		git checkout $branch || exit
 		;;
 	refs/heads/*|$_x40)
-		[ -s "$GIT_DIR/head-name" ] && die "won't bisect on seeked tree"
 		echo "${head#refs/heads/}" >"$GIT_DIR/head-name"
 		;;
 	*)
@@ -365,7 +364,6 @@ bisect_reset() {
 	    usage ;;
 	esac
 	if git checkout "$branch"; then
-		rm -f "$GIT_DIR/head-name"
 		bisect_clean_state
 	fi
 }
@@ -377,6 +375,7 @@ bisect_clean_state() {
 	do
 		git update-ref -d $ref $hash
 	done
+	rm -f "$GIT_DIR/head-name"
 	rm -f "$GIT_DIR/BISECT_LOG"
 	rm -f "$GIT_DIR/BISECT_NAMES"
 	rm -f "$GIT_DIR/BISECT_RUN"
-- 
1.5.4.1