bisect help

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> writes:

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.

On Tue, Jun 27, 2006 at 02:31:09PM -0700, Junio C Hamano wrote:

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

Jeff King <peff@peff.net> writes:

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.

On Tue, Jun 27, 2006 at 03:41:16PM -0700, Junio C Hamano wrote:

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