# bisect help 5 messages from 2006-06-27 to 2006-06-27. Participants: Martin Hicks, Junio C Hamano, Jeff King. Thread: https://gitlist.dev/t/4686 ## Martin Hicks, 2006-06-27 20:13 Subject: bisect help Message-ID: <20060627201302.GA16658@bork.org> URL: https://gitlist.dev/e/20060627201302.GA16658%40bork.org ``` I've got a use-case that I can't figure out. The problem: - I have a tree with 2.6.17 + changes to make my target board work. - SATA works as of 2.6.17, but stops working in the libata dev tree. I want to do a bisect on this to figure out why. I think the problem is that the common ancestor between the two trees is 2.6.17, and when I bisect I don't have any of my arch-specific changes still in the tree (so the kernel doesn't boot, but not for SATA reasons) I have my tree in "master", Jeff's SATA tree in "satadev". I've tried a few things like: git checkout -b garbage master git pull . satadev # to get all the sata changes git bisect start git bisect bad git bisect good master but it seems like this causes the bisect to happen between the common ancestor (v2.6.17) and the merge of master & satadev. help! thanks mh -- Martin Hicks || mort@bork.org || PGP/GnuPG: 0x4C7F2BEE ``` ## Junio C Hamano, 2006-06-27 21:31 Subject: Re: bisect help Message-ID: <7vy7vi70bm.fsf@assigned-by-dhcp.cox.net> URL: https://gitlist.dev/e/7vy7vi70bm.fsf%40assigned-by-dhcp.cox.net In-Reply-To: <20060627201302.GA16658@bork.org> ``` Martin Hicks writes: > I've got a use-case that I can't figure out. The problem: > > - I have a tree with 2.6.17 + changes to make my target board work. > - SATA works as of 2.6.17, but stops working in the libata dev tree. > > I want to do a bisect on this to figure out why. I think the problem is > that the common ancestor between the two trees is 2.6.17, and when I > bisect I don't have any of my arch-specific changes still in the tree > (so the kernel doesn't boot, but not for SATA reasons) I suspect this is what you have. o---o---o---o satadev / / / 2.6.17 o---o---o---o---o master In order to test, since vanilla "satadev" would not work with your board (for that matter neither vanilla 2.6.17 would), I presume you would have created a throw-away test branch and merged them for testing: o---o---o---o satadev / \ / o test / / 2.6.17 o---o---o---o---o master You say master works but test does not. But everything between 2.6.17 and satadev would not work with your board *anyway*, so bisect by itself is not very useful between master and test. I think you could bisect between 2.6.17 and satadev, and every time bisect suggests to test a revision (that is, it moves the head of .git/refs/heads/bisect branch), temporarily merge "master" in for testing, and discard that temporary merge after you finished testing, like this: bisect o---o---o---o satadev / \ / .-------o test / / 2.6.17 o---o---o---o---o master $ git bisect good 2.6.17 $ git bisect bad satadev Bisectiong: 1745 revisions left to test after this [a04da91...] arch/i386/kernel/apic.c: make modern_... $ git pull . master .. test this thing .. $ git reset --hard HEAD^ $ git bisect bad ;# if it is bad Bisectiong: 1745 revisions left to test after this [050335d...] Merge branch 'devel' of ... $ git pull . master .. test this thing .. $ git reset --hard HEAD^ If your merges involve textual conflicts, it might be worthwhile to enable git-rerere when you do this. ``` ## Jeff King, 2006-06-27 22:04 Subject: Re: bisect help Message-ID: <20060627220421.GA7234@coredump.intra.peff.net> URL: https://gitlist.dev/e/20060627220421.GA7234%40coredump.intra.peff.net In-Reply-To: <7vy7vi70bm.fsf@assigned-by-dhcp.cox.net> ``` On Tue, Jun 27, 2006 at 02:31:09PM -0700, Junio C Hamano wrote: > o---o---o---o satadev > / \ > / o test > / / > 2.6.17 o---o---o---o---o master > > You say master works but test does not. But everything between > 2.6.17 and satadev would not work with your board *anyway*, so > bisect by itself is not very useful between master and test. Since 'test' is a throwaway branch anyway, might it not make sense to clone master to test and then rebase satadev onto it? Thus you would end up with the linear history: o---o---o---o---o---o---o test (satadev') | | 2.6.17 master You know that master works and satadev' doesn't, and the bisection is simple. After you find that bug, you can throw away the test branch. -Peff ``` ## Junio C Hamano, 2006-06-27 22:41 Subject: Re: bisect help Message-ID: <7vu0666x2r.fsf@assigned-by-dhcp.cox.net> URL: https://gitlist.dev/e/7vu0666x2r.fsf%40assigned-by-dhcp.cox.net In-Reply-To: <20060627220421.GA7234@coredump.intra.peff.net> ``` Jeff King writes: > Since 'test' is a throwaway branch anyway, might it not make sense to > clone master to test and then rebase satadev onto it? Thus you would end > up with the linear history: > o---o---o---o---o---o---o test (satadev') > | | > 2.6.17 master > > You know that master works and satadev' doesn't, and the bisection is > simple. After you find that bug, you can throw away the test branch. I've considered suggesting it before looking at what is in satadev. It is merged up in the Linus head right now, so you are talking about really _huge_ changes that are not yours and with a lot of merges. It usually is much easier to rebase your own code than other's. BTW, I really hate MUA's that does Mail-Followup-To to somebody else. This message for example would not help Martin more than it would help you, but your MUA somehow redirected it to him. ``` ## Martin Hicks, 2006-06-27 22:59 Subject: Re: bisect help Message-ID: <20060627225944.GB16658@bork.org> URL: https://gitlist.dev/e/20060627225944.GB16658%40bork.org In-Reply-To: <7vu0666x2r.fsf@assigned-by-dhcp.cox.net> ``` On Tue, Jun 27, 2006 at 03:41:16PM -0700, Junio C Hamano wrote: > Jeff King writes: > > > Since 'test' is a throwaway branch anyway, might it not make sense to > > clone master to test and then rebase satadev onto it? Thus you would end > > up with the linear history: > > o---o---o---o---o---o---o test (satadev') > > | | > > 2.6.17 master > > > > You know that master works and satadev' doesn't, and the bisection is > > simple. After you find that bug, you can throw away the test branch. > > I've considered suggesting it before looking at what is in > satadev. It is merged up in the Linus head right now, so you > are talking about really _huge_ changes that are not yours and > with a lot of merges. > > It usually is much easier to rebase your own code than other's. > > BTW, I really hate MUA's that does Mail-Followup-To to somebody > else. This message for example would not help Martin more than > it would help you, but your MUA somehow redirected it to him. I think the rebase idea is going to be painful. There are a *lot* of changesets in between 2.6.17 and satadev, due to the post-2.6.17 devel cycle opening. I rebasing quickly, but it would require a bit of merging. I'll try tomorrow to see how bad it really is. Thank you both for the ideas. I think I've got enough information now to continue. mh -- Martin Hicks || mort@bork.org || PGP/GnuPG: 0x4C7F2BEE ```