Re: git-bisect problem

Andrew Morton [off-list ref] writes:

Junio C Hamano [off-list ref] wrote:

quoted

Andrew Morton [off-list ref] writes:

quoted

My current theory is that I was bisecting Linus's tree all along.

Sorry, I did not realize that was _not_ what you were doing.
Your log started by saying 2.6.16-rc1 is good but 2.6.16-rc2 was
not, so I just assumed your bug was between those two.

So how am I supposed to find this bug in Jeff's tree?

Sorry, this question is what I do not quite understand.

Here is my understanding of the situation.

 - Betweeen 2.6.16-rc1 and 2.6.16-rc2 a bug you are chasing was
   introduced.  You know rc1 works fine but rc2 is bad.

 - You suspect that changes introduced by merging Jeff's tree
   at some point between -rc1 and -rc2 may be causing this.

Am I totally misunderstanding the situation?

Bisecting, starting from -rc1 and -rc2 marked good and bad would
find the bug provided if the symptom is caused by a single bug
(that is, before that commit things work but after that things
stop working) that is in any commit that was not present in -rc1
but in -rc2.  That includes what was merged from Jeff's tree, so
even if you were "bisecting Linus' tree all along", if -rc1 was
good and -rc2 was bad, that would have found the bug in Jeff's
tree (if it was what introduced the bug).  As long as that was
merged between these two -- but otherwise breakage in -rc2 would
not have anything to do with Jeff's tree, so that is one reason
I am confused by your emphasis on "in Jeff's tree" part.


              good                     bad
              -rc1                     -rc2
    ---o---o---o---*---*---*---*---*---*
        \           \     /   /
         \           *---*   /
          \                 / 
           *---*---*---*---*
                Jeff's       

Your bisection that starts with good -rc1 and bad -rc2 would try
to bisect commits that are not reachable from good ones (that
is, parents before good ones are assumed to be good, since
bisect is only good to look for a single regression), so at the
beginning, all '*' commits are suspects.  bisection picks one of
them and after testing it, depending on it is good or bad, mark
about the half of the remaining graph "unsuspected".  So even if
you start out with two commits on Linus' tree, you will wander
into Jeff's tree, if the suspect commit is in there.  I am
confused by your emphasis on "in Jeff's tree" part.

Maybe you are saying that you _know_ what broke was from Jeff's
tree, and felt bisecting other parts of Linus' tree was
wasteful?

If so, you can use gitk to visualize the graph, find the merge
Linus' did to merge from Jeff (and I presume you already did so
and that is why you are suspecting Jeff's tree).  Mark that as
bad, not -rc2.  Also if you know the commit on Linus' tree
before that merge was good (and I presume you already did so
and that is why you are suspecting Jeff's tree), mark that as
good, not -rc1.

              -rc1      good  bad     -rc2
    ---o---o---o---o---o---o---*---o---o
        \           \     /   /
         \           o---o   /
          \                 / 
           *---*---*---*---*
                Jeff's       

Then your bisect will walk over commits on Jeff's tree.

Is this helpful, or am I still completely useless?