Re: git-bisect problem

From: Junio C Hamano <junkio@cox.net>
Date: Feb 14, 2006, 00:32 UTC
Message-ID: <7v8xsezsni.fsf@assigned-by-dhcp.cox.net>
In-Reply-To: <20060213021917.742b2b10.akpm@osdl.org>

Andrew Morton <akpm@osdl.org> writes:

Show 11 quoted lines

> Junio C Hamano <junkio@cox.net> wrote:
>>
>> Andrew Morton <akpm@osdl.org> writes:
>> 
>> > 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?