bisect help

bisect help

[Martin Hicks]

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

Re: bisect help

[Junio C Hamano]

Martin Hicks <mort@bork.org> 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.

Re: bisect help

[Jeff King]

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

Re: bisect help

[Junio C Hamano]

Jeff King <peff@peff.net> 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.

Re: bisect help

[Martin Hicks]

On Tue, Jun 27, 2006 at 03:41:16PM -0700, Junio C Hamano wrote:
> Jeff King <peff@peff.net> 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