{"thread":{"id":"4686","subject":"bisect help","startedAt":"2006-06-27T20:13:02Z","lastAt":"2006-06-27T22:59:44Z","messageCount":5,"participants":["Martin Hicks","Junio C Hamano","Jeff King"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"22685","messageId":"20060627201302.GA16658@bork.org","threadId":"4686","inReplyTo":null,"subject":"bisect help","fromName":"Martin Hicks","fromEmail":"mort@bork.org","sentAt":"2006-06-27T20:13:02Z","receivedAt":"2006-06-27T20:13:02Z","isPatch":false,"sender":{"key":"mort@bork.org","avatar":null},"body":"\nI've got a use-case that I can't figure out. The problem:\n\n- I have a tree with 2.6.17 + changes to make my target board work.\n- SATA works as of 2.6.17, but stops working in the libata dev tree.\n\nI want to do a bisect on this to figure out why. I think the problem is\nthat the common ancestor between the two trees is 2.6.17, and when I\nbisect I don't have any of my arch-specific changes still in the tree\n(so the kernel doesn't boot, but not for SATA reasons)\n\nI have my tree in \"master\", Jeff's SATA tree in \"satadev\". I've tried a\nfew things like:\n\ngit checkout -b garbage master\ngit pull . satadev\t\t\t# to get all the sata changes\ngit bisect start\ngit bisect bad\ngit bisect good master\n\nbut it seems like this causes the bisect to happen between the common\nancestor (v2.6.17) and the merge of master & satadev.\n\nhelp!\nthanks\nmh\n\n-- \nMartin Hicks || mort@bork.org || PGP/GnuPG: 0x4C7F2BEE\n"},{"id":"22687","messageId":"7vy7vi70bm.fsf@assigned-by-dhcp.cox.net","threadId":"4686","inReplyTo":"20060627201302.GA16658@bork.org","subject":"Re: bisect help","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2006-06-27T21:31:09Z","receivedAt":"2006-06-27T21:31:09Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Martin Hicks writes:\n\n> I've got a use-case that I can't figure out. The problem:\n>\n> - I have a tree with 2.6.17 + changes to make my target board work.\n> - SATA works as of 2.6.17, but stops working in the libata dev tree.\n>\n> I want to do a bisect on this to figure out why. I think the problem is\n> that the common ancestor between the two trees is 2.6.17, and when I\n> bisect I don't have any of my arch-specific changes still in the tree\n> (so the kernel doesn't boot, but not for SATA reasons)\n\nI suspect this is what you have.\n\n \n o---o---o---o satadev\n /\n /\n /\n 2.6.17 o---o---o---o---o master\n\nIn order to test, since vanilla \"satadev\" would not work with\nyour board (for that matter neither vanilla 2.6.17 would), I\npresume you would have created a throw-away test branch and\nmerged them for testing:\n \n o---o---o---o satadev\n / \\ \n / o test\n / / \n 2.6.17 o---o---o---o---o master\n\nYou say master works but test does not. But everything between\n2.6.17 and satadev would not work with your board *anyway*, so\nbisect by itself is not very useful between master and test.\n\nI think you could bisect between 2.6.17 and satadev, and every\ntime bisect suggests to test a revision (that is, it moves the\nhead of .git/refs/heads/bisect branch), temporarily merge\n\"master\" in for testing, and discard that temporary merge after\nyou finished testing, like this:\n\n bisect \n o---o---o---o satadev\n / \\\n / .-------o test\n / / \n 2.6.17 o---o---o---o---o master\n\n\t$ git bisect good 2.6.17\n $ git bisect bad satadev\n Bisectiong: 1745 revisions left to test after this\n\t[a04da91...] arch/i386/kernel/apic.c: make modern_...\n $ git pull . master\n .. test this thing ..\n $ git reset --hard HEAD^\n $ git bisect bad ;# if it is bad\n Bisectiong: 1745 revisions left to test after this\n\t[050335d...] Merge branch 'devel' of ...\n $ git pull . master\n .. test this thing ..\n $ git reset --hard HEAD^\n\nIf your merges involve textual conflicts, it might be worthwhile\nto enable git-rerere when you do this.\n"},{"id":"22688","messageId":"20060627220421.GA7234@coredump.intra.peff.net","threadId":"4686","inReplyTo":"7vy7vi70bm.fsf@assigned-by-dhcp.cox.net","subject":"Re: bisect help","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2006-06-27T22:04:21Z","receivedAt":"2006-06-27T22:04:21Z","isPatch":false,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Tue, Jun 27, 2006 at 02:31:09PM -0700, Junio C Hamano wrote:\n\n> o---o---o---o satadev\n> / \\ \n> / o test\n> / / \n> 2.6.17 o---o---o---o---o master\n> \n> You say master works but test does not. But everything between\n> 2.6.17 and satadev would not work with your board *anyway*, so\n> bisect by itself is not very useful between master and test.\n\nSince 'test' is a throwaway branch anyway, might it not make sense to\nclone master to test and then rebase satadev onto it? Thus you would end\nup with the linear history:\n o---o---o---o---o---o---o test (satadev')\n | |\n2.6.17 master\n\nYou know that master works and satadev' doesn't, and the bisection is\nsimple. After you find that bug, you can throw away the test branch.\n\n-Peff\n"},{"id":"22692","messageId":"7vu0666x2r.fsf@assigned-by-dhcp.cox.net","threadId":"4686","inReplyTo":"20060627220421.GA7234@coredump.intra.peff.net","subject":"Re: bisect help","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2006-06-27T22:41:16Z","receivedAt":"2006-06-27T22:41:16Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Jeff King writes:\n\n> Since 'test' is a throwaway branch anyway, might it not make sense to\n> clone master to test and then rebase satadev onto it? Thus you would end\n> up with the linear history:\n> o---o---o---o---o---o---o test (satadev')\n> | |\n> 2.6.17 master\n>\n> You know that master works and satadev' doesn't, and the bisection is\n> simple. After you find that bug, you can throw away the test branch.\n\nI've considered suggesting it before looking at what is in\nsatadev. It is merged up in the Linus head right now, so you\nare talking about really _huge_ changes that are not yours and\nwith a lot of merges.\n\nIt usually is much easier to rebase your own code than other's.\n\nBTW, I really hate MUA's that does Mail-Followup-To to somebody\nelse. This message for example would not help Martin more than\nit would help you, but your MUA somehow redirected it to him.\n"},{"id":"22695","messageId":"20060627225944.GB16658@bork.org","threadId":"4686","inReplyTo":"7vu0666x2r.fsf@assigned-by-dhcp.cox.net","subject":"Re: bisect help","fromName":"Martin Hicks","fromEmail":"mort@bork.org","sentAt":"2006-06-27T22:59:44Z","receivedAt":"2006-06-27T22:59:44Z","isPatch":false,"sender":{"key":"mort@bork.org","avatar":null},"body":"\nOn Tue, Jun 27, 2006 at 03:41:16PM -0700, Junio C Hamano wrote:\n> Jeff King writes:\n> \n> > Since 'test' is a throwaway branch anyway, might it not make sense to\n> > clone master to test and then rebase satadev onto it? Thus you would end\n> > up with the linear history:\n> > o---o---o---o---o---o---o test (satadev')\n> > | |\n> > 2.6.17 master\n> >\n> > You know that master works and satadev' doesn't, and the bisection is\n> > simple. After you find that bug, you can throw away the test branch.\n> \n> I've considered suggesting it before looking at what is in\n> satadev. It is merged up in the Linus head right now, so you\n> are talking about really _huge_ changes that are not yours and\n> with a lot of merges.\n> \n> It usually is much easier to rebase your own code than other's.\n> \n> BTW, I really hate MUA's that does Mail-Followup-To to somebody\n> else. This message for example would not help Martin more than\n> it would help you, but your MUA somehow redirected it to him.\n\nI think the rebase idea is going to be painful. There are a *lot* of\nchangesets in between 2.6.17 and satadev, due to the post-2.6.17 devel\ncycle opening.\n\nI rebasing quickly, but it would require a bit of merging. I'll try\ntomorrow to see how bad it really is.\n\nThank you both for the ideas. I think I've got enough information now\nto continue.\n\nmh\n\n-- \nMartin Hicks || mort@bork.org || PGP/GnuPG: 0x4C7F2BEE\n"}]}