* Christian Couder <chriscool@xxxxxxxxxxxxx> wrote: > > # > > # So perhaps this new, unnamed branch is what is causing the trouble? > > # Lets try a specific branch then: > > # > > > > dione:~/linux-tmp4> git-checkout master > > Previous HEAD position was 4991408... Linux 2.6.24 > > Switched to branch "master" > > > > dione:~/linux-tmp4> git-bisect start > > won't bisect on seeked tree > > This seems to work for me with git 1.5.5 on the git tree: > What git version do you have ? git-core-1.5.4.3-2.fc8, like for the previous report. and it worked for me too in a later tree - so the condition seems transient. > > dione:~/linux-tmp4> git-bisect good v2.6.24 bad HEAD > > dione:~/linux-tmp4> > > This is really bad, because, as you can see from the man page or "git > bisect -h" (see also the patch I just sent), "git bisect good" can > take many known good revisions: > > git bisect good [<rev>...] > mark <rev>... known-good revisions. > > So you marked also "bad" and HEAD as "good". > > This is really strange, because here I get for example: > > $ git-bisect good bad HEAD > Bad rev input: bad HEAD > > So you must have something tagged as "bad" or have a "bad" branch, and > that's why the command works for you but does the wrong thing. no, there are no 'bad' braches or revisions. and ... if "git-bisect good X bad Y" is invalid syntax it should be detected by the tool ... I did not think up that syntax myself, i think i saw it somewhere else mentioned by someone and found it logical. Weird. Generally i do use the separate commands though. > > dione:~/linux-tmp5> git-bisect visualize > > You need to give me at least one good and one bad revisions. > > (You can use "git bisect bad" and "git bisect good" for that.) > > dione:~/linux-tmp5> git bisect bad HEAD > > dione:~/linux-tmp5> git bisect good v2.6.24 > > Bisecting: -1 revisions left to test after this > > [eb36f4fc019835cecf0788907f6cab774508087b] fix oops on rmmod capidrv > > That's much better but you didn't "reset" or "start" again before > giving it correctly the good and bad revs, so there are still some > wrong left over from your previous start above. > > > # > > # -1 revisions left to test? Ouch ... > > # > > # But why did "git bisect" make a difference to "git-bisect" ? > > It should not have made any difference. it probably didnt - i was just grasping at straws because there was no reassuring feedback about what happened so my confidence about my _assumptions_ what was happening in the background gradually eroded so i went in larger and larger circles around the problem dropping more and more assumptions and re-checking them. But i pasted this directly from that session so the "-1" is definitely not imaginery and it is anomalous. Ingo -- 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