Re: bisect help

Martin Hicks [off-list ref] 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.

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