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
Junio C HamanoRe: Clueless bisect error message
"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.
Nguyen Thai Ngoc DuyRe: Clueless bisect error message
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
Junio C HamanoRe: Clueless bisect error message
"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.
Nguyen Thai Ngoc DuyRe: Clueless bisect error message
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
Jeff KingRe: Clueless bisect error message
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
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
Jeff KingRe: Clueless bisect error message
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