{"thread":{"id":"17993","subject":"git bisect goes wild?","startedAt":"2009-02-24T18:44:14Z","lastAt":"2009-02-24T21:15:07Z","messageCount":8,"participants":["Jan Kara","Peter Harris","Teemu Likonen","Daniel Barkalow"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"106090","messageId":"20090224184414.GE22108@duck.suse.cz","threadId":"17993","inReplyTo":null,"subject":"git bisect goes wild?","fromName":"Jan Kara","fromEmail":"jack@suse.cz","sentAt":"2009-02-24T18:44:14Z","receivedAt":"2009-02-24T18:44:14Z","isPatch":false,"sender":{"key":"jack@suse.cz","avatar":null},"body":"  Hi,\n\n  I've been bisecting some change in Linux kernel. The output of\n\"git bisect log\" is:\ngit-bisect start\n# good: [bbf25010f1a6b761914430f5fca081ec8c7accd1] Linux 2.6.23\ngit-bisect good bbf25010f1a6b761914430f5fca081ec8c7accd1\n# bad: [49914084e797530d9baaf51df9eda77babc98fa8] Linux 2.6.24\ngit-bisect bad 49914084e797530d9baaf51df9eda77babc98fa8\n# bad: [fe071d7e8aae5745c009c808bb8933f22a9e305a] oom: add\n# oom_kill_allocating_task sysctl\ngit-bisect bad fe071d7e8aae5745c009c808bb8933f22a9e305a\n# good: [117494a1b65183f0e3fcc817b07944bc5c465050] Merge\n# master.kernel.org:/pub/scm/linux/kernel/git/gregkh/usb-2.6\ngit-bisect good 117494a1b65183f0e3fcc817b07944bc5c465050\n# bad: [419217cb1d0266f62cbea6cdc6b1d1324350bc34] Merge branch\n# 'v2.6.24-lockdep' of\n# git://git.kernel.org/pub/scm/linux/kernel/git/peterz/linux-2.6-lockdep\ngit-bisect bad 419217cb1d0266f62cbea6cdc6b1d1324350bc34\n# good: [c8c55bcb43d790d97790cfa319d80045a71fde39] Merge\n# git://git.infradead.org/mtd-2.6\ngit-bisect good c8c55bcb43d790d97790cfa319d80045a71fde39\n# good: [3e9830dcabdeb3656855ec1b678b6bcf3b50261c] sched: run\n# sched_domain_debug() if CONFIG_SCHED_DEBUG=y\ngit-bisect good 3e9830dcabdeb3656855ec1b678b6bcf3b50261c\n\n  But after the last command, I was sent to commit\n9ec76fbf7d6da3e98070a7059699d0ca019b0c9b which is far outside the window\nbetween the last good and bad commit. How come? git version is 1.5.6.\n  Thanks for any suggestions.\n\n\t\t\t\t\t\t\t\tHonza\n\nPS: Please CC me since I'm not on the list.\n-- \nJan Kara <jack@suse.cz>\nSUSE Labs, CR\n"},{"id":"106091","messageId":"eaa105840902241059y70143c43s7d12b10fe35127e6@mail.gmail.com","threadId":"17993","inReplyTo":"20090224184414.GE22108@duck.suse.cz","subject":"Re: git bisect goes wild?","fromName":"Peter Harris","fromEmail":"git@peter.is-a-geek.org","sentAt":"2009-02-24T18:59:16Z","receivedAt":"2009-02-24T18:59:16Z","isPatch":false,"sender":{"key":"git@peter.is-a-geek.org","avatar":null},"body":"2009/2/24 Jan Kara:\n>  Hi,\n>\n>  I've been bisecting some change in Linux kernel. The output of\n> \"git bisect log\" is:\n...\n> git-bisect bad 419217cb1d0266f62cbea6cdc6b1d1324350bc34\n...\n> git-bisect good 3e9830dcabdeb3656855ec1b678b6bcf3b50261c\n>\n>  But after the last command, I was sent to commit\n> 9ec76fbf7d6da3e98070a7059699d0ca019b0c9b which is far outside the window\n> between the last good and bad commit.\n\nHow did you determine that this commit is outside the window?\n\nWhen I run \"gitk 3e9830..419217\" it shows that commit, as does \"git\nlog\". 9ec76fb appears to be inside the window to me.\n\nPeter Harris\n"},{"id":"106092","messageId":"20090224191002.GF22108@duck.suse.cz","threadId":"17993","inReplyTo":"eaa105840902241059y70143c43s7d12b10fe35127e6@mail.gmail.com","subject":"Re: git bisect goes wild?","fromName":"Jan Kara","fromEmail":"jack@suse.cz","sentAt":"2009-02-24T19:10:02Z","receivedAt":"2009-02-24T19:10:02Z","isPatch":false,"sender":{"key":"jack@suse.cz","avatar":null},"body":"On Tue 24-02-09 13:59:16, Peter Harris wrote:\n> 2009/2/24 Jan Kara:\n> >  Hi,\n> >\n> >  I've been bisecting some change in Linux kernel. The output of\n> > \"git bisect log\" is:\n> ...\n> > git-bisect bad 419217cb1d0266f62cbea6cdc6b1d1324350bc34\n> ...\n> > git-bisect good 3e9830dcabdeb3656855ec1b678b6bcf3b50261c\n> >\n> >  But after the last command, I was sent to commit\n> > 9ec76fbf7d6da3e98070a7059699d0ca019b0c9b which is far outside the window\n> > between the last good and bad commit.\n> \n> How did you determine that this commit is outside the window?\n> \n> When I run \"gitk 3e9830..419217\" it shows that commit, as does \"git\n> log\". 9ec76fb appears to be inside the window to me.\n  Ho, hum, right. But if I do:\ngit describe 9ec76fbf7d6da3e98070a7059699d0ca019b0c9b\n  I get v2.6.23-rc3-215-g9ec76fb which is a bit strange for bisecting\nbetween 2.6.23 and 2.6.24. Also the kernel gets named 2.6.23-rc3 and kernel\nconfig options get also to some pre 2.6.23 state. That's what is confusing\nme. It seems like the kernel checked out is some old one. I'm not a git\nexpert so it might be fine but it just seems really strange.\n\n\t\t\t\t\t\t\t\t\tHonza\n-- \nJan Kara <jack@suse.cz>\nSUSE Labs, CR\n"},{"id":"106094","messageId":"87prh7abqz.fsf@iki.fi","threadId":"17993","inReplyTo":"20090224191002.GF22108@duck.suse.cz","subject":"Re: git bisect goes wild?","fromName":"Teemu Likonen","fromEmail":"tlikonen@iki.fi","sentAt":"2009-02-24T19:14:12Z","receivedAt":"2009-02-24T19:14:12Z","isPatch":false,"sender":{"key":"tlikonen@iki.fi","avatar":null},"body":"On 2009-02-24 20:10 (+0100), Jan Kara wrote:\n\n>   Ho, hum, right. But if I do:\n> git describe 9ec76fbf7d6da3e98070a7059699d0ca019b0c9b\n>   I get v2.6.23-rc3-215-g9ec76fb which is a bit strange for bisecting\n> between 2.6.23 and 2.6.24. Also the kernel gets named 2.6.23-rc3 and\n> kernel config options get also to some pre 2.6.23 state. That's what\n> is confusing me. It seems like the kernel checked out is some old one.\n> I'm not a git expert so it might be fine but it just seems really\n> strange.\n\nMaybe this explanation helps:\n\nhttp://thread.gmane.org/gmane.comp.version-control.git/99967/focus=99977\n"},{"id":"106095","messageId":"20090224192809.GG22108@duck.suse.cz","threadId":"17993","inReplyTo":"87prh7abqz.fsf@iki.fi","subject":"Re: git bisect goes wild?","fromName":"Jan Kara","fromEmail":"jack@suse.cz","sentAt":"2009-02-24T19:28:10Z","receivedAt":"2009-02-24T19:28:10Z","isPatch":false,"sender":{"key":"jack@suse.cz","avatar":null},"body":"On Tue 24-02-09 21:14:12, Teemu Likonen wrote:\n> On 2009-02-24 20:10 (+0100), Jan Kara wrote:\n> \n> >   Ho, hum, right. But if I do:\n> > git describe 9ec76fbf7d6da3e98070a7059699d0ca019b0c9b\n> >   I get v2.6.23-rc3-215-g9ec76fb which is a bit strange for bisecting\n> > between 2.6.23 and 2.6.24. Also the kernel gets named 2.6.23-rc3 and\n> > kernel config options get also to some pre 2.6.23 state. That's what\n> > is confusing me. It seems like the kernel checked out is some old one.\n> > I'm not a git expert so it might be fine but it just seems really\n> > strange.\n> \n> Maybe this explanation helps:\n> \n> http://thread.gmane.org/gmane.comp.version-control.git/99967/focus=99977\n  OK, thanks for the pointer. I'll trust that the result will be sensible\n:).\n\n\t\t\t\t\t\t\t\t\tHonza\n-- \nJan Kara <jack@suse.cz>\nSUSE Labs, CR\n"},{"id":"106097","messageId":"alpine.LNX.1.00.0902241427420.19665@iabervon.org","threadId":"17993","inReplyTo":"20090224191002.GF22108@duck.suse.cz","subject":"Re: git bisect goes wild?","fromName":"Daniel Barkalow","fromEmail":"barkalow@iabervon.org","sentAt":"2009-02-24T19:46:09Z","receivedAt":"2009-02-24T19:46:09Z","isPatch":false,"sender":{"key":"barkalow@iabervon.org","avatar":"https://avatars.githubusercontent.com/u/55364219?v=4"},"body":"On Tue, 24 Feb 2009, Jan Kara wrote:\n\n> On Tue 24-02-09 13:59:16, Peter Harris wrote:\n> > 2009/2/24 Jan Kara:\n> > >  Hi,\n> > >\n> > >  I've been bisecting some change in Linux kernel. The output of\n> > > \"git bisect log\" is:\n> > ...\n> > > git-bisect bad 419217cb1d0266f62cbea6cdc6b1d1324350bc34\n> > ...\n> > > git-bisect good 3e9830dcabdeb3656855ec1b678b6bcf3b50261c\n> > >\n> > >  But after the last command, I was sent to commit\n> > > 9ec76fbf7d6da3e98070a7059699d0ca019b0c9b which is far outside the window\n> > > between the last good and bad commit.\n> > \n> > How did you determine that this commit is outside the window?\n> > \n> > When I run \"gitk 3e9830..419217\" it shows that commit, as does \"git\n> > log\". 9ec76fb appears to be inside the window to me.\n>   Ho, hum, right. But if I do:\n> git describe 9ec76fbf7d6da3e98070a7059699d0ca019b0c9b\n>   I get v2.6.23-rc3-215-g9ec76fb which is a bit strange for bisecting\n> between 2.6.23 and 2.6.24. Also the kernel gets named 2.6.23-rc3 and kernel\n> config options get also to some pre 2.6.23 state. That's what is confusing\n> me. It seems like the kernel checked out is some old one. I'm not a git\n> expert so it might be fine but it just seems really strange.\n\nIf you're trying to find a problem that got into the mainline kernel \nbetween 2.6.23 and 2.6.24, you should expect to find a change that was \nadded less than 2 weeks after 2.6.23 was released, and written before \n2.6.23 was released. Such a change would probably have been written \nagainst a mainline kernel somewhere in the 2.6.23-rcN range. So the \ndescription you should expect of the version that introduces the bug is \n\"2.6.23-rcN with some patches that hadn't been merged to mainline\".\n\nIn order for your bisect to end up with a commit that looks like it's \nbetween 2.6.23 and 2.6.24, Linus would have to have merged a buggy commit \nfor 2.6.24 written after 2.6.23 was released, which is against how things \nare supposed to be done.\n\n\t-Daniel\n*This .sig left intentionally blank*"},{"id":"106099","messageId":"20090224200416.GH22108@duck.suse.cz","threadId":"17993","inReplyTo":"alpine.LNX.1.00.0902241427420.19665@iabervon.org","subject":"Re: git bisect goes wild?","fromName":"Jan Kara","fromEmail":"jack@suse.cz","sentAt":"2009-02-24T20:04:16Z","receivedAt":"2009-02-24T20:04:16Z","isPatch":false,"sender":{"key":"jack@suse.cz","avatar":null},"body":"On Tue 24-02-09 14:46:09, Daniel Barkalow wrote:\n> On Tue, 24 Feb 2009, Jan Kara wrote:\n> \n> > On Tue 24-02-09 13:59:16, Peter Harris wrote:\n> > > 2009/2/24 Jan Kara:\n> > > >  Hi,\n> > > >\n> > > >  I've been bisecting some change in Linux kernel. The output of\n> > > > \"git bisect log\" is:\n> > > ...\n> > > > git-bisect bad 419217cb1d0266f62cbea6cdc6b1d1324350bc34\n> > > ...\n> > > > git-bisect good 3e9830dcabdeb3656855ec1b678b6bcf3b50261c\n> > > >\n> > > >  But after the last command, I was sent to commit\n> > > > 9ec76fbf7d6da3e98070a7059699d0ca019b0c9b which is far outside the window\n> > > > between the last good and bad commit.\n> > > \n> > > How did you determine that this commit is outside the window?\n> > > \n> > > When I run \"gitk 3e9830..419217\" it shows that commit, as does \"git\n> > > log\". 9ec76fb appears to be inside the window to me.\n> >   Ho, hum, right. But if I do:\n> > git describe 9ec76fbf7d6da3e98070a7059699d0ca019b0c9b\n> >   I get v2.6.23-rc3-215-g9ec76fb which is a bit strange for bisecting\n> > between 2.6.23 and 2.6.24. Also the kernel gets named 2.6.23-rc3 and kernel\n> > config options get also to some pre 2.6.23 state. That's what is confusing\n> > me. It seems like the kernel checked out is some old one. I'm not a git\n> > expert so it might be fine but it just seems really strange.\n> \n> If you're trying to find a problem that got into the mainline kernel \n> between 2.6.23 and 2.6.24, you should expect to find a change that was \n> added less than 2 weeks after 2.6.23 was released, and written before \n> 2.6.23 was released. Such a change would probably have been written \n> against a mainline kernel somewhere in the 2.6.23-rcN range. So the \n> description you should expect of the version that introduces the bug is \n> \"2.6.23-rcN with some patches that hadn't been merged to mainline\".\n> \n> In order for your bisect to end up with a commit that looks like it's \n> between 2.6.23 and 2.6.24, Linus would have to have merged a buggy commit \n> for 2.6.24 written after 2.6.23 was released, which is against how things \n> are supposed to be done.\n  Yes, thanks for explanation. I've figured it out as well after reading\nthe posted link. What makes me a bit afraid is that bugs (or especially\nperformance regression, which is what I'm hunting right now) can be caused\nby interference of two independent changes. I.e., in a situation like:\n  A-B-C-D\n   \\_E_/\n\n  if I start bisecting between B and D and the problem happens only when\nboth C and E are merged, then the best what I can end up with is that the\nmerge-commit is what causes the regression, isn't it? Which is sometimes\nuseless when the merge commit is a merge of some branch with 1000\npatches...\n  So it might be useful if git-bisect had a \"linear\" mode - we would first\ncreate a linear history of commits and then bisect in it. Now I understand\nthat this is not always possible (sometimes changes would not apply) but it\nshould be possible when merges are trivial (i.e., all commits apply cleanly\nto the source just before the merge commit - and this is quite often the\ncase at least with the Linux kernel). Just my 2 cents.\n\n\t\t\t\t\t\t\t\tHonza\n-- \nJan Kara <jack@suse.cz>\nSUSE Labs, CR\n"},{"id":"106104","messageId":"alpine.LNX.1.00.0902241553310.19665@iabervon.org","threadId":"17993","inReplyTo":"20090224200416.GH22108@duck.suse.cz","subject":"Re: git bisect goes wild?","fromName":"Daniel Barkalow","fromEmail":"barkalow@iabervon.org","sentAt":"2009-02-24T21:15:07Z","receivedAt":"2009-02-24T21:15:07Z","isPatch":false,"sender":{"key":"barkalow@iabervon.org","avatar":"https://avatars.githubusercontent.com/u/55364219?v=4"},"body":"On Tue, 24 Feb 2009, Jan Kara wrote:\n\n> On Tue 24-02-09 14:46:09, Daniel Barkalow wrote:\n> > On Tue, 24 Feb 2009, Jan Kara wrote:\n> > \n> > > On Tue 24-02-09 13:59:16, Peter Harris wrote:\n> > > > 2009/2/24 Jan Kara:\n> > > > >  Hi,\n> > > > >\n> > > > >  I've been bisecting some change in Linux kernel. The output of\n> > > > > \"git bisect log\" is:\n> > > > ...\n> > > > > git-bisect bad 419217cb1d0266f62cbea6cdc6b1d1324350bc34\n> > > > ...\n> > > > > git-bisect good 3e9830dcabdeb3656855ec1b678b6bcf3b50261c\n> > > > >\n> > > > >  But after the last command, I was sent to commit\n> > > > > 9ec76fbf7d6da3e98070a7059699d0ca019b0c9b which is far outside the window\n> > > > > between the last good and bad commit.\n> > > > \n> > > > How did you determine that this commit is outside the window?\n> > > > \n> > > > When I run \"gitk 3e9830..419217\" it shows that commit, as does \"git\n> > > > log\". 9ec76fb appears to be inside the window to me.\n> > >   Ho, hum, right. But if I do:\n> > > git describe 9ec76fbf7d6da3e98070a7059699d0ca019b0c9b\n> > >   I get v2.6.23-rc3-215-g9ec76fb which is a bit strange for bisecting\n> > > between 2.6.23 and 2.6.24. Also the kernel gets named 2.6.23-rc3 and kernel\n> > > config options get also to some pre 2.6.23 state. That's what is confusing\n> > > me. It seems like the kernel checked out is some old one. I'm not a git\n> > > expert so it might be fine but it just seems really strange.\n> > \n> > If you're trying to find a problem that got into the mainline kernel \n> > between 2.6.23 and 2.6.24, you should expect to find a change that was \n> > added less than 2 weeks after 2.6.23 was released, and written before \n> > 2.6.23 was released. Such a change would probably have been written \n> > against a mainline kernel somewhere in the 2.6.23-rcN range. So the \n> > description you should expect of the version that introduces the bug is \n> > \"2.6.23-rcN with some patches that hadn't been merged to mainline\".\n> > \n> > In order for your bisect to end up with a commit that looks like it's \n> > between 2.6.23 and 2.6.24, Linus would have to have merged a buggy commit \n> > for 2.6.24 written after 2.6.23 was released, which is against how things \n> > are supposed to be done.\n>   Yes, thanks for explanation. I've figured it out as well after reading\n> the posted link. What makes me a bit afraid is that bugs (or especially\n> performance regression, which is what I'm hunting right now) can be caused\n> by interference of two independent changes. I.e., in a situation like:\n>   A-B-C-D\n>    \\_E_/\n> \n>   if I start bisecting between B and D and the problem happens only when\n> both C and E are merged, then the best what I can end up with is that the\n> merge-commit is what causes the regression, isn't it? Which is sometimes\n> useless when the merge commit is a merge of some branch with 1000\n> patches...\n\nYou'll end up with it blaming D, yes.\n\n>   So it might be useful if git-bisect had a \"linear\" mode - we would first\n> create a linear history of commits and then bisect in it. Now I understand\n> that this is not always possible (sometimes changes would not apply) but it\n> should be possible when merges are trivial (i.e., all commits apply cleanly\n> to the source just before the merge commit - and this is quite often the\n> case at least with the Linux kernel). Just my 2 cents.\n\nLinearizing wouldn't really give entirely accurate results for bisecting a \ncombination; you would get one of the sides where the problem starts, but \nyou wouldn't know what it conflicts with. The ideal thing would actually \nbe to first find that some particular merge is bad, and then bisect each \nside individually, looking for the first commit on each side that, when \nthey're merged together, produces a result with the problem. In any case, \ndoing much more complicated than the current bisect requires being able to \nautomate a complicated sequence of operations (going back to the user at \ncertain points, because it may be necessary to do a manual merge to test), \nwhich hasn't been made practical yet.\n\n\t-Daniel\n*This .sig left intentionally blank*"}]}