Re: bisect help

From: Junio C Hamano <junkio@cox.net>
Date: Jun 27, 2006, 21:31 UTC
Message-ID: <7vy7vi70bm.fsf@assigned-by-dhcp.cox.net>
In-Reply-To: <20060627201302.GA16658@bork.org>

Martin Hicks <mort@bork.org> writes:

Show 9 quoted lines

> 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.