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

[Thiago Macieira]

Em quarta-feira, 9 de fevereiro de 2011, às 04:29:28, Boyd Stephen Smith Jr. 
escreveu:
> A-*---*-B
>  \     /
>   *-*-*
> A = Good
> B = Bad
> 
> Yes, no middle point, and if the commits were linear, then there would be 
> exactly one to choose.  However, there are other cases where a non-linear 
> history allows git bisect to test fewer commits, instead of
> more.  (Basically,  almost any time a merge commit and the merge-base of
> all it's parents are either good or bad.)

Right. If A is good and B is good, then all intervening commits should be good 
too. Similarly if both are bad.

But the problem is that you had to test both A and B first to find that out. 
Imagine this:

  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.

You can't choose a middle-point in either side of the branch: if you choose 
any commit in the AYB branch, all will test "good". If you chose Z, it would 
also test "good".

Instead, you have to test both of B^1 and B^2. You have to identify first which 
side of the branch has the fault -- and note that both could be good, in which 
case the merge is the fault. (I guess it actually doesn't test all parents, 
just N-1 and then moves on to normal linear bisecting -- the merge commit 
being the faulty one would be a worst-case scenario, but also an unlikely one)

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.

-- 
Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
  Senior Product Manager - Nokia, Qt Development Frameworks
      PGP/GPG: 0x6EF45358; fingerprint:
      E067 918B B660 DBD1 105C  966C 33F5 F005 6EF4 5358
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 190 bytes
Desc: This is a digitally signed message part.
Url : http://mail.kde.org/pipermail/kde-scm-interest/attachments/20110209/74da5928/attachment.sig