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@xxxxxxxxxx>
---
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
-
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
