Clueless bisect error message

Clueless bisect error message

[Nguyen Thai Ngoc Duy]

$ git bisect start
won't bisect on seeked tree

It complained because .git/head-name contained 't' which had been
deleted before. git-bisect reset works. However I'd request git-bisect
to inform more useful messages. At first, I was completely stunned:
"what is a seeked tree? how can I fix that?"
-- 
Duy

Re: Clueless bisect error message

[Junio C Hamano]

"Nguyen Thai Ngoc Duy" <pclouds@gmail.com> writes:

> $ git bisect start
> won't bisect on seeked tree
>
> It complained because .git/head-name contained 't' which had been
> deleted before. git-bisect reset works. However I'd request git-bisect
> to inform more useful messages. At first, I was completely stunned:
> "what is a seeked tree? how can I fix that?"

Interesting.  There is certainly something clueless but I am not
sure if it is git-bisect.

Other git-core tools never create $GIT_DIR/head-name unless
bisect is in effect, and you end your bisect session by doing
"bisect reset" (otherwise there is no easy way to get back to
your original branch head).  How did head-name got 't' in it,
and how was branch 't' removed?

If the answer to the first question is because earlier you
created a temporary branch 't' to run a bisect, and the answer
to the latter is because you ended your bisect session by saying
"git checkout -f someotherbranch && git branch -D t", then we
should be able to fix that by removing head-name upon branch
switching with "git checkout".

By looking at commit 810255f, however, I suspect that fix would
break Cogito.  The wording of the message actually comes from
Cogito nomenclature.

Re: Clueless bisect error message

[Nguyen Thai Ngoc Duy]

On 10/11/06, Junio C Hamano <junkio@cox.net> wrote:
> "Nguyen Thai Ngoc Duy" <pclouds@gmail.com> writes:
>
> > $ git bisect start
> > won't bisect on seeked tree
> >
> > It complained because .git/head-name contained 't' which had been
> > deleted before. git-bisect reset works. However I'd request git-bisect
> > to inform more useful messages. At first, I was completely stunned:
> > "what is a seeked tree? how can I fix that?"
>
> Interesting.  There is certainly something clueless but I am not
> sure if it is git-bisect.
>
> Other git-core tools never create $GIT_DIR/head-name unless
> bisect is in effect, and you end your bisect session by doing
> "bisect reset" (otherwise there is no easy way to get back to
> your original branch head).  How did head-name got 't' in it,
> and how was branch 't' removed?
Well, I probably removed it myself. It's one of my temporary branches
IIRC. Perhaps I forgot  to do "bisect reset".

>
> If the answer to the first question is because earlier you
> created a temporary branch 't' to run a bisect, and the answer
> to the latter is because you ended your bisect session by saying
> "git checkout -f someotherbranch && git branch -D t", then we
> should be able to fix that by removing head-name upon branch
> switching with "git checkout".
That might be the case. I used bisect on this repo a long ago. I'm not
sure what actually happened.

>
> By looking at commit 810255f, however, I suspect that fix would
> break Cogito.  The wording of the message actually comes from
> Cogito nomenclature.
Ah. I forgot to say I'm using git 1.4.2.1. My only wish is not a fix
(unless it's a trivial fix) but that bisect should explain the
situation better and guide people to fix it. I had grepped bisect man
page for "seeked tree" and was still clueless.
-- 
Duy

Re: Clueless bisect error message

[Junio C Hamano]

"Nguyen Thai Ngoc Duy" <pclouds@gmail.com> writes:

>> By looking at commit 810255f, however, I suspect that fix would
>> break Cogito.  The wording of the message actually comes from
>> Cogito nomenclature.
> Ah. I forgot to say I'm using git 1.4.2.1. My only wish is not a fix
> (unless it's a trivial fix) but that bisect should explain the
> situation better and guide people to fix it. I had grepped bisect man
> page for "seeked tree" and was still clueless.

My point actually was that even a simple rewording is harder
than it seems, because that cluelessness actually was introduced
to help Cogito.  If we do not care about it, we can just reword
it to say "Hey you are in the middle of another bisect, or maybe
you left your bisect by doing git-checkout earlier?  In either
case git-bisect --reset is your friend, oh, and we can run that
for you now if you want".  We could even remove head-name in
git-checkout when we see one.

But I suspect that doing either of these things would harm
Cogito users.  After cg-seek the user is not "in the middle of
another bisect", and if we run "git bisect --reset" when we see
head-name, it would probably break it too.

Re: Clueless bisect error message

[Nguyen Thai Ngoc Duy]

On 10/11/06, Junio C Hamano <junkio@cox.net> wrote:
> My point actually was that even a simple rewording is harder
> than it seems, because that cluelessness actually was introduced
> to help Cogito.  If we do not care about it, we can just reword
> it to say "Hey you are in the middle of another bisect, or maybe
> you left your bisect by doing git-checkout earlier?  In either
> case git-bisect --reset is your friend, oh, and we can run that
> for you now if you want".  We could even remove head-name in
> git-checkout when we see one.
>
> But I suspect that doing either of these things would harm
> Cogito users.  After cg-seek the user is not "in the middle of
> another bisect", and if we run "git bisect --reset" when we see
> head-name, it would probably break it too.
Thanks. Now I understand the issue. I'm sorry for my ignorant because
I haven't used cogito yet.

-- 
Duy

Re: Clueless bisect error message

[Jeff King]

On Wed, Oct 11, 2006 at 01:11:42AM -0700, Junio C Hamano wrote:

> But I suspect that doing either of these things would harm
> Cogito users.  After cg-seek the user is not "in the middle of
> another bisect", and if we run "git bisect --reset" when we see
> head-name, it would probably break it too.

Maybe expand head-name to include a "reason" field? Unfortunately we
can't just stick it in the same file and remain compatible with all
versions, so we'll have to use a new file. Something like:

-- >8 --
git-bisect: use head-reason to explain use of head-name

Since many different programs may use head-name to indicate that the working
tree should not be modified, head-reason gives them a chance to explain what
they're doing. This can improve the accuracy of error messages (such as won't
bisect a seeked tree).

Signed-off-by: Jeff King <peff@peff.net>
---
Alternatively, the actual message to show the user could be placed in
head-reason. I think it makes more sense as it is, as it provides the
ability for the message to say "can't X because of Y" in plain English.

And of course we need cogito to start supporting this (but we print
something sane for older versions with don't support head-reason).

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

diff --git a/git-bisect.sh b/git-bisect.sh
index 06a8d26..9f49dd3 100755
--- a/git-bisect.sh
+++ b/git-bisect.sh
@@ -57,8 +57,21 @@ bisect_start() {
 		git checkout $branch || exit
 		;;
 	refs/heads/*)
-		[ -s "$GIT_DIR/head-name" ] && die "won't bisect on seeked tree"
+		if [ -s "$GIT_DIR/head-name" ]; then
+		    case "$(cat "$GIT_DIR/head-reason" 2>/dev/null)" in
+		    bisect)
+			die "You are already in the middle of another bisect!"
+			;;
+		    seek)
+			die "You can't bisect a seeked tree!"
+			;;
+		    *)
+			die "head-name already exists"
+			;;
+		    esac
+		fi
 		echo "$head" | sed 's#^refs/heads/##' >"$GIT_DIR/head-name"
+		echo bisect >"$GIT_DIR/head-reason"
 		;;
 	*)
 		die "Bad HEAD - strange symbolic ref"
@@ -182,6 +195,7 @@ bisect_reset() {
 	git checkout "$branch" &&
 	rm -fr "$GIT_DIR/refs/bisect"
 	rm -f "$GIT_DIR/refs/heads/bisect" "$GIT_DIR/head-name"
+	rm -f "$GIT_DIR/head-reason"
 	rm -f "$GIT_DIR/BISECT_LOG"
 	rm -f "$GIT_DIR/BISECT_NAMES"
 }
-- 
1.4.2.3.g2c59-dirty



> 
> -
> To unsubscribe from this list: send the line "unsubscribe git" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: Clueless bisect error message

[Krzysztof Halasa]

Jeff King <peff@peff.net> writes:

> +			die "You can't bisect a seeked tree!"

Just to make sure: dictionary.reference.com doesn't know the
"seeked" word (I don't either though that may be normal).

Should it read "sought"? Not sure what does the message talk about.
-- 
Krzysztof Halasa

Re: Clueless bisect error message

[Jeff King]

On Wed, Oct 11, 2006 at 02:51:29PM +0200, Krzysztof Halasa wrote:

> > +			die "You can't bisect a seeked tree!"
> Just to make sure: dictionary.reference.com doesn't know the
> "seeked" word (I don't either though that may be normal).
> 
> Should it read "sought"? Not sure what does the message talk about.

Seeked is not a "real" word in the sense of being in any dictionary. The
past participle form of "seek" is indeed "sought" (though one might want
to use the passive perfect participle form "being sought" for this
case).

However, the use of the word "sought" implies to me the classical
definition of the word seek: "to look for something." The definition we
are using here is a more modern, computer-oriented definition: "to move
to a position within an ordered set" (since we are referring to Cogito's
cg-seek command). Just as you might verbify (another non-word!) a
command and say "I catted those files together", the tree has been
"seeked." One could argue it should be "cat'd" and "seek'd" to indicate
their non-word status, but that idiom is common enough among
programmers, especially Unix users, that I suspect it will make sense
either way.

At any rate, the word "seeked" was in the original error message, so I
didn't introduce it. Are other people bothered by it?

-Peff