git.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
* bisect: "won't bisect on seeked tree"
@ 2008-02-21  5:20 Mike Galbraith
  2008-02-21  5:33 ` Shawn O. Pearce
  2008-02-21 17:32 ` [PATCH] Eliminate confusing "won't bisect on seeked tree" failure Carl Worth
  0 siblings, 2 replies; 11+ messages in thread
From: Mike Galbraith @ 2008-02-21  5:20 UTC (permalink / raw)
  To: git

Greetings,

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?

	-Mike

^ permalink raw reply	[flat|nested] 11+ messages in thread

* Re: bisect: "won't bisect on seeked tree"
  2008-02-21  5:20 bisect: "won't bisect on seeked tree" Mike Galbraith
@ 2008-02-21  5:33 ` Shawn O. Pearce
  2008-02-21  5:39   ` Mike Galbraith
  2008-02-21 17:32 ` [PATCH] Eliminate confusing "won't bisect on seeked tree" failure Carl Worth
  1 sibling, 1 reply; 11+ messages in thread
From: Shawn O. Pearce @ 2008-02-21  5:33 UTC (permalink / raw)
  To: Mike Galbraith; +Cc: git

Mike Galbraith <efault@gmx.de> 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?

I think you are already in the middle of a bisect.

Try "git bisect reset" first to get out of the current bisect before
starting another one.

-- 
Shawn.

^ permalink raw reply	[flat|nested] 11+ messages in thread

* Re: bisect: "won't bisect on seeked tree"
  2008-02-21  5:33 ` Shawn O. Pearce
@ 2008-02-21  5:39   ` Mike Galbraith
  2008-02-21  5:43     ` Shawn O. Pearce
  0 siblings, 1 reply; 11+ messages in thread
From: Mike Galbraith @ 2008-02-21  5:39 UTC (permalink / raw)
  To: Shawn O. Pearce; +Cc: git


On Thu, 2008-02-21 at 00:33 -0500, Shawn O. Pearce wrote:
> Mike Galbraith <efault@gmx.de> 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?
> 
> I think you are already in the middle of a bisect.
> 
> Try "git bisect reset" first to get out of the current bisect before
> starting another one.

It says "We are not bisecting".

	-Mike

^ permalink raw reply	[flat|nested] 11+ messages in thread

* Re: bisect: "won't bisect on seeked tree"
  2008-02-21  5:39   ` Mike Galbraith
@ 2008-02-21  5:43     ` Shawn O. Pearce
  2008-02-21  6:00       ` Mike Galbraith
  0 siblings, 1 reply; 11+ messages in thread
From: Shawn O. Pearce @ 2008-02-21  5:43 UTC (permalink / raw)
  To: Mike Galbraith; +Cc: git

Mike Galbraith <efault@gmx.de> wrote:
> On Thu, 2008-02-21 at 00:33 -0500, Shawn O. Pearce wrote:
> > Mike Galbraith <efault@gmx.de> 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?
> > 
> > I think you are already in the middle of a bisect.
> > 
> > Try "git bisect reset" first to get out of the current bisect before
> > starting another one.
> 
> It says "We are not bisecting".

Your repository is in a funny state.  The file .git/BISECT_NAMES
was removed but .git/head-name was not.  Deleting .git/head-name
should resolve the issue.  But it would be interesting to know how
the repository came into this state.

-- 
Shawn.

^ permalink raw reply	[flat|nested] 11+ messages in thread

* Re: bisect: "won't bisect on seeked tree"
  2008-02-21  5:43     ` Shawn O. Pearce
@ 2008-02-21  6:00       ` Mike Galbraith
  0 siblings, 0 replies; 11+ messages in thread
From: Mike Galbraith @ 2008-02-21  6:00 UTC (permalink / raw)
  To: Shawn O. Pearce; +Cc: git


On Thu, 2008-02-21 at 00:43 -0500, Shawn O. Pearce wrote:
> Mike Galbraith <efault@gmx.de> wrote:
> > On Thu, 2008-02-21 at 00:33 -0500, Shawn O. Pearce wrote:
> > > Mike Galbraith <efault@gmx.de> 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?
> > > 
> > > I think you are already in the middle of a bisect.
> > > 
> > > Try "git bisect reset" first to get out of the current bisect before
> > > starting another one.
> > 
> > It says "We are not bisecting".
> 
> Your repository is in a funny state.  The file .git/BISECT_NAMES
> was removed but .git/head-name was not.  Deleting .git/head-name
> should resolve the issue.  But it would be interesting to know how
> the repository came into this state.

Bingo, thanks!

There's only one git user here, so I have a good idea who to blame...
but he (me) is claiming innocence.  The content of head-name was
"master" fwiw.

	-Mike

^ permalink raw reply	[flat|nested] 11+ messages in thread

* [PATCH] Eliminate confusing "won't bisect on seeked tree" failure
  2008-02-21  5:20 bisect: "won't bisect on seeked tree" Mike Galbraith
  2008-02-21  5:33 ` Shawn O. Pearce
@ 2008-02-21 17:32 ` Carl Worth
  2008-02-22 17:18   ` Junio C Hamano
  1 sibling, 1 reply; 11+ messages in thread
From: Carl Worth @ 2008-02-21 17:32 UTC (permalink / raw)
  To: Mike Galbraith; +Cc: git

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

^ permalink raw reply related	[flat|nested] 11+ messages in thread

* Re: [PATCH] Eliminate confusing "won't bisect on seeked tree" failure
  2008-02-21 17:32 ` [PATCH] Eliminate confusing "won't bisect on seeked tree" failure Carl Worth
@ 2008-02-22 17:18   ` Junio C Hamano
  2008-02-23  9:21     ` Karl Hasselström
  2008-02-23 18:33     ` Carl Worth
  0 siblings, 2 replies; 11+ messages in thread
From: Junio C Hamano @ 2008-02-22 17:18 UTC (permalink / raw)
  To: Carl Worth; +Cc: Mike Galbraith, git

Carl Worth <cworth@cworth.org> writes:

> 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 message itself refers to a Cogito "feature" and I suspect
that removing the check and refusal would confuse Cogito.  While
I think the patch itself is Ok for us, we may want to wait a bit
for a while. until Cogito users all die out.

^ permalink raw reply	[flat|nested] 11+ messages in thread

* Re: [PATCH] Eliminate confusing "won't bisect on seeked tree" failure
  2008-02-22 17:18   ` Junio C Hamano
@ 2008-02-23  9:21     ` Karl Hasselström
  2008-02-23 18:33     ` Carl Worth
  1 sibling, 0 replies; 11+ messages in thread
From: Karl Hasselström @ 2008-02-23  9:21 UTC (permalink / raw)
  To: Junio C Hamano; +Cc: Carl Worth, Mike Galbraith, git

On 2008-02-22 09:18:03 -0800, Junio C Hamano wrote:

> While I think the patch itself is Ok for us, we may want to wait a
> bit for a while. until Cogito users all die out.

Or until they stop use Cogito. Whichever happens first. ;-)

-- 
Karl Hasselström, kha@treskal.com
      www.treskal.com/kalle

^ permalink raw reply	[flat|nested] 11+ messages in thread

* Re: [PATCH] Eliminate confusing "won't bisect on seeked tree" failure
  2008-02-22 17:18   ` Junio C Hamano
  2008-02-23  9:21     ` Karl Hasselström
@ 2008-02-23 18:33     ` Carl Worth
  2008-02-23 22:59       ` Junio C Hamano
  1 sibling, 1 reply; 11+ messages in thread
From: Carl Worth @ 2008-02-23 18:33 UTC (permalink / raw)
  To: Junio C Hamano; +Cc: Mike Galbraith, git

[-- Attachment #1: Type: text/plain, Size: 3197 bytes --]

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.

Note: We preserve the warning for any cogito users. We do this
by switching from .git/head-name to .git/BISECT_START for the
extra state, (which is a more descriptive name anyway).

Signed-off-by: Carl Worth <cworth@cworth.org>
---
 On Fri, 22 Feb 2008 09:18:03 -0800, Junio C Hamano wrote:
 > The message itself refers to a Cogito "feature" and I suspect
 > that removing the check and refusal would confuse Cogito.  While
 > I think the patch itself is Ok for us, we may want to wait a bit
 > for a while. until Cogito users all die out.

 To avoid confusing cogito, this version preserves the error if
 there is a .git/head-name file around from cg-seek, and instead
 uses .git/BISECT_START for the git-bisect state.

 Does this seem safe enough, Junio?

 I suppose this does mean that cogito won't consider the tree to
 be in a "seeked" state during a git-bisect session, but hopefully
 that's not a big problem.

 Any cogito users around that really care one way or the other on
 this stuff?

 -Carl

 git-bisect.sh |   16 ++++++++++------
 1 files changed, 10 insertions(+), 6 deletions(-)

diff --git a/git-bisect.sh b/git-bisect.sh
index 74715ed..4b13388 100755
--- a/git-bisect.sh
+++ b/git-bisect.sh
@@ -67,16 +67,18 @@ bisect_start() {
 	die "Bad HEAD - I need a HEAD"
 	case "$head" in
 	refs/heads/bisect)
-		if [ -s "$GIT_DIR/head-name" ]; then
-		    branch=`cat "$GIT_DIR/head-name"`
+		if [ -s "$GIT_DIR/BISECT_START" ]; then
+		    branch=`cat "$GIT_DIR/BISECT_START"`
 		else
 		    branch=master
 		fi
 		git checkout $branch || exit
 		;;
 	refs/heads/*|$_x40)
+		# This error message should only be triggered by cogito usage,
+		# and cogito users should understand it relates to cg-seek.
 		[ -s "$GIT_DIR/head-name" ] && die "won't bisect on seeked tree"
-		echo "${head#refs/heads/}" >"$GIT_DIR/head-name"
+		echo "${head#refs/heads/}" >"$GIT_DIR/BISECT_START"
 		;;
 	*)
 		die "Bad HEAD - strange symbolic ref"
@@ -353,8 +355,8 @@ bisect_reset() {
 		return
 	}
 	case "$#" in
-	0) if [ -s "$GIT_DIR/head-name" ]; then
-	       branch=`cat "$GIT_DIR/head-name"`
+	0) if [ -s "$GIT_DIR/BISECT_START" ]; then
+	       branch=`cat "$GIT_DIR/BISECT_START"`
 	   else
 	       branch=master
 	   fi ;;
@@ -365,7 +367,6 @@ bisect_reset() {
 	    usage ;;
 	esac
 	if git checkout "$branch"; then
-		rm -f "$GIT_DIR/head-name"
 		bisect_clean_state
 	fi
 }
@@ -377,6 +378,9 @@ bisect_clean_state() {
 	do
 		git update-ref -d $ref $hash
 	done
+	# Cleanup head-name if it got left by an old version of git-bisect
+	rm -f "$GIT_DIR/head-name"
+	rm -f "$GIT_DIR/BISECT_START"
 	rm -f "$GIT_DIR/BISECT_LOG"
 	rm -f "$GIT_DIR/BISECT_NAMES"
 	rm -f "$GIT_DIR/BISECT_RUN"
--
1.5.4.1


[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

^ permalink raw reply related	[flat|nested] 11+ messages in thread

* Re: [PATCH] Eliminate confusing "won't bisect on seeked tree" failure
  2008-02-23 18:33     ` Carl Worth
@ 2008-02-23 22:59       ` Junio C Hamano
  2008-02-24  1:14         ` Carl Worth
  0 siblings, 1 reply; 11+ messages in thread
From: Junio C Hamano @ 2008-02-23 22:59 UTC (permalink / raw)
  To: Carl Worth; +Cc: Mike Galbraith, git

Carl Worth <cworth@cworth.org> writes:

>  Does this seem safe enough, Junio?

Neither the earlier one nor this one passes t6030.

^ permalink raw reply	[flat|nested] 11+ messages in thread

* Re: [PATCH] Eliminate confusing "won't bisect on seeked tree" failure
  2008-02-23 22:59       ` Junio C Hamano
@ 2008-02-24  1:14         ` Carl Worth
  0 siblings, 0 replies; 11+ messages in thread
From: Carl Worth @ 2008-02-24  1:14 UTC (permalink / raw)
  To: Junio C Hamano; +Cc: Mike Galbraith, git

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.

Note: We preserve the warning for any cogito users. We do this
by switching from .git/head-name to .git/BISECT_START for the
extra state, (which is a more descriptive name anyway).

Signed-off-by: Carl Worth <cworth@cworth.org>
---
 On Sat, 23 Feb 2008 14:59:38 -0800, Junio C Hamano wrote:
 > Neither the earlier one nor this one passes t6030.

 Thanks. Both versions were definitely broken, and two of the three
 failures were a good catch of the bug I had introduced.

 The third failure was simply that the test needed to be updated to
 track the change from head-name to BISECT_START.

 And a quick "git grep head-name" of the source suggests that no other
 stale uses of head-name remain, (the things left in git-bisect are
 intentional for cogito compatibility as described above, and the
 things in git-rebase all refer to $DOTEST/head-name which is
 distinct.

 Third time's the charm by chance?

 -Carl

 git-bisect.sh               |   14 +++++++++-----
 t/t6030-bisect-porcelain.sh |    2 +-
 2 files changed, 10 insertions(+), 6 deletions(-)

diff --git a/git-bisect.sh b/git-bisect.sh
index 74715ed..2c32d0b 100755
--- a/git-bisect.sh
+++ b/git-bisect.sh
@@ -67,16 +67,18 @@ bisect_start() {
 	die "Bad HEAD - I need a HEAD"
 	case "$head" in
 	refs/heads/bisect)
-		if [ -s "$GIT_DIR/head-name" ]; then
-		    branch=`cat "$GIT_DIR/head-name"`
+		if [ -s "$GIT_DIR/BISECT_START" ]; then
+		    branch=`cat "$GIT_DIR/BISECT_START"`
 		else
 		    branch=master
 		fi
 		git checkout $branch || exit
 		;;
 	refs/heads/*|$_x40)
+		# This error message should only be triggered by cogito usage,
+		# and cogito users should understand it relates to cg-seek.
 		[ -s "$GIT_DIR/head-name" ] && die "won't bisect on seeked tree"
-		echo "${head#refs/heads/}" >"$GIT_DIR/head-name"
+		echo "${head#refs/heads/}" >"$GIT_DIR/BISECT_START"
 		;;
 	*)
 		die "Bad HEAD - strange symbolic ref"
@@ -353,8 +355,8 @@ bisect_reset() {
 		return
 	}
 	case "$#" in
-	0) if [ -s "$GIT_DIR/head-name" ]; then
-	       branch=`cat "$GIT_DIR/head-name"`
+	0) if [ -s "$GIT_DIR/BISECT_START" ]; then
+	       branch=`cat "$GIT_DIR/BISECT_START"`
 	   else
 	       branch=master
 	   fi ;;
@@ -365,7 +367,9 @@ bisect_reset() {
 	    usage ;;
 	esac
 	if git checkout "$branch"; then
+		# Cleanup head-name if it got left by an old version of git-bisect
 		rm -f "$GIT_DIR/head-name"
+		rm -f "$GIT_DIR/BISECT_START"
 		bisect_clean_state
 	fi
 }
diff --git a/t/t6030-bisect-porcelain.sh b/t/t6030-bisect-porcelain.sh
index ec71123..4908e87 100755
--- a/t/t6030-bisect-porcelain.sh
+++ b/t/t6030-bisect-porcelain.sh
@@ -260,7 +260,7 @@ test_expect_success 'bisect starting with a detached HEAD' '
 	git checkout master^ &&
 	HEAD=$(git rev-parse --verify HEAD) &&
 	git bisect start &&
-	test $HEAD = $(cat .git/head-name) &&
+	test $HEAD = $(cat .git/BISECT_START) &&
 	git bisect reset &&
 	test $HEAD = $(git rev-parse --verify HEAD)
 
-- 
1.5.4.1

^ permalink raw reply related	[flat|nested] 11+ messages in thread

end of thread, other threads:[~2008-02-24  1:15 UTC | newest]

Thread overview: 11+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2008-02-21  5:20 bisect: "won't bisect on seeked tree" Mike Galbraith
2008-02-21  5:33 ` Shawn O. Pearce
2008-02-21  5:39   ` Mike Galbraith
2008-02-21  5:43     ` Shawn O. Pearce
2008-02-21  6:00       ` Mike Galbraith
2008-02-21 17:32 ` [PATCH] Eliminate confusing "won't bisect on seeked tree" failure Carl Worth
2008-02-22 17:18   ` Junio C Hamano
2008-02-23  9:21     ` Karl Hasselström
2008-02-23 18:33     ` Carl Worth
2008-02-23 22:59       ` Junio C Hamano
2008-02-24  1:14         ` Carl Worth

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).