On Tue, 24 Feb 2009, Jan Kara wrote: > On Tue 24-02-09 13:59:16, Peter Harris wrote: > > 2009/2/24 Jan Kara: > > > Hi, > > > > > > I've been bisecting some change in Linux kernel. The output of > > > "git bisect log" is: > > ... > > > git-bisect bad 419217cb1d0266f62cbea6cdc6b1d1324350bc34 > > ... > > > git-bisect good 3e9830dcabdeb3656855ec1b678b6bcf3b50261c > > > > > > But after the last command, I was sent to commit > > > 9ec76fbf7d6da3e98070a7059699d0ca019b0c9b which is far outside the window > > > between the last good and bad commit. > > > > How did you determine that this commit is outside the window? > > > > When I run "gitk 3e9830..419217" it shows that commit, as does "git > > log". 9ec76fb appears to be inside the window to me. > Ho, hum, right. But if I do: > git describe 9ec76fbf7d6da3e98070a7059699d0ca019b0c9b > I get v2.6.23-rc3-215-g9ec76fb which is a bit strange for bisecting > between 2.6.23 and 2.6.24. Also the kernel gets named 2.6.23-rc3 and kernel > config options get also to some pre 2.6.23 state. That's what is confusing > me. It seems like the kernel checked out is some old one. I'm not a git > expert so it might be fine but it just seems really strange. If you're trying to find a problem that got into the mainline kernel between 2.6.23 and 2.6.24, you should expect to find a change that was added less than 2 weeks after 2.6.23 was released, and written before 2.6.23 was released. Such a change would probably have been written against a mainline kernel somewhere in the 2.6.23-rcN range. So the description you should expect of the version that introduces the bug is "2.6.23-rcN with some patches that hadn't been merged to mainline". In order for your bisect to end up with a commit that looks like it's between 2.6.23 and 2.6.24, Linus would have to have merged a buggy commit for 2.6.24 written after 2.6.23 was released, which is against how things are supposed to be done. -Daniel *This .sig left intentionally blank*
