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

[Johannes Sixt]

Am 2/9/2011 18:26, schrieb Thiago Macieira:
> On Wednesday, 9 de February de 2011 14:35:34 Johannes Sixt wrote:
>> 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.
> 
> Hmm... Let me see if I understand:
> 
> Let's instead list the commits by their state: good and bad. Remember that all 
> the y commits are good.
> 
> y1 z1 z2 y2 z3 z4 Z Y X z5 y3 z6 z7 y4 z8 z9 y5
> G  G  G  G  G  G  G G B B  G  B  B  G  B  B  G
> 
> If I choose one of the z commits to the left of X (let's say, Z), they'll test 
> Good, which means I can exclude the A-Z commits from my list.

Correct.

> If I choose one 
> of the z commits to the right of X, they'll test bad and I should exclude from 
> there to B.

But since you now know that the regression somewhere between A and (say)
z8, you can exclude all y commits as well! We never have to look at the
AYB branch anymore, and now we removed more than half of the commits, not
fewer!

> If I choose a commit from the AYB branch (say, Y), and it tests 
> good, I can only exclude A-Y, whe the remainder commits still left (y3 to y5).

Correct.

> So this is a bisection, but a weird one because you're still excluding less 
> than half of the remaining commits, as you're jumping from branch to branch. 

Not quite. It's more true to say that half of the time it takes more
tests, the other half it takes fewer.

> Anyway, the point is made: since you are excluding less than half at each 
> iteration, the number of iterations to find the culprit is actually bigger than 
> a linear history.

Please make a fair comparison: You cannot say "lets say it picks this and
that commit" and compare the outcome to an optimal linear bisection,
because git picks commits in a smarter way than you did in the examples above.

-- Hannes