On Tue, 24 Feb 2009, Jan Kara wrote: > 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... You'll end up with it blaming D, yes. > 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. Linearizing wouldn't really give entirely accurate results for bisecting a combination; you would get one of the sides where the problem starts, but you wouldn't know what it conflicts with. The ideal thing would actually be to first find that some particular merge is bad, and then bisect each side individually, looking for the first commit on each side that, when they're merged together, produces a result with the problem. In any case, doing much more complicated than the current bisect requires being able to automate a complicated sequence of operations (going back to the user at certain points, because it may be necessary to do a manual merge to test), which hasn't been made practical yet. -Daniel *This .sig left intentionally blank*
