On Tue 24-02-09 14:46:09, Daniel Barkalow wrote: > 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. Yes, thanks for explanation. I've figured it out as well after reading the posted link. What makes me a bit afraid is that bugs (or especially performance regression, which is what I'm hunting right now) can be caused by interference of two independent changes. I.e., in a situation like: A-B-C-D \_E_/ if I start bisecting between B and D and the problem happens only when both C and E are merged, then the best what I can end up with is that the merge-commit is what causes the regression, isn't it? Which is sometimes useless when the merge commit is a merge of some branch with 1000 patches... So it might be useful if git-bisect had a "linear" mode - we would first create a linear history of commits and then bisect in it. Now I understand that this is not always possible (sometimes changes would not apply) but it should be possible when merges are trivial (i.e., all commits apply cleanly to the source just before the merge commit - and this is quite often the case at least with the Linux kernel). Just my 2 cents. Honza -- Jan Kara <jack@xxxxxxx> SUSE Labs, CR -- 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
