[Kde-scm-interest] Re: Usage of pull rebasing and merges

[Johannes Sixt]

Am 2/9/2011 12:47, schrieb Thiago Macieira:
>   good--*--A--*--*--*--*--Z--X--*--*--*--*--*---B--bad
>             \                                  /
>              *-----*--------Y-----*-----*-----*
> 
> Suppose X marks the spot and Y and Z are innocent. In order to bisect this and 
> find X, knowing the two boundaries, you need to check that B is bad and A is 
> good.
> ...
> The point is that whenever you have a fault between a branch and a merge, you 
> need to stop bisecting and instead exclude branches. That is not bisecting and 
> could, under circumstances, require more tests than proper bisecting.

Don't you misunderstand something here? You have to inspect the parents of
the merge only if you want know *in advance* in which branch the
regression is. But you do not have to know this to *find* the regression.

Take your example above. Name the '*' in the upper line between A and B z1
to z9, and in the lower line y1 to y5. When you know A is good and B is
bad, you only have to list the commits in any linearized order, for example,

  y1 z1 z2 y2 z3 z4 Z Y X z5 y3 z6 z7 y4 z8 z9 y5

and test the one in the middle. That happens to be X. It is a bad commit.
At this point, you know that the regression was introduzed by one of z1,
z2, z3, z4, Z, or X. Or if you picked Y, you would strike y1, y2, and Y
from the list and repeat. See? You never have to know on "which branch"
you are.

-- Hannes