Re: [RFC] Add bad-branch-first option for git-bisect

[Shuang He <shuang.he@intel.com>]

On 2011/1/25 4:04, Junio C Hamano wrote:
> Shuang He<shuang.he@intel.com>  writes:
>
>> If A is bad commit, and C fixed it, and then F is bad again,
>>
>> A ->   B ->   C ->   D ->   E ->   F ->   G ->   H   (master)
>>    \                    \      /
>>      a  ->   b... c ->   d ->   e->f  (feature 1)
>>
>> Start with H as bad commit, and D as good commit, it's possible git-bisect would jump to c, and it will lead to wrong direction
>>
>> If bad-branch-first is used, it would be:
>> 1. first round found F
>> 2. end
> It is unclear from the way you drew the picture if "F" is supposed to be a
> merge of "E" and "f", but I'd assume that it is.

Oh, I lost this mail
That graph is different from what I meant, when shown in different email 
client.
It's G which is merged from e and F

> So what you are saying in 1. is "skip from H until you hit a first merge
> (without testing any intermediate commit), find F and stop to check it,
> and find that it is broken".
>
> What makes you decide "2. end"?  The fact that both of its parents "E" and
> "f" are Ok?  IOW, it won't be "2. end" if one of the parents of the merge
> is broken?

I think the correction above should have answer those two questions.

> What if there is _no_ merge from a side branch but there were breakages in
> A (fixed in C) and then F in your original picture, i.e.
>
>    A---B---C---D---E---F---G---H (broken)
>    x       o           x
>
> and you are hunting for the bug starting from H?  How does your algorithm
> help?  I grossed over the linear part by saying "skip from H until you hit
> a first merge", but in general, what is your plan to handle linear part of
> the history?

If the history is linear, the new algorithm won't help, it will just 
behavior like default git-bisect algorithm.

> A totally unacceptable answer is "It does not help linear case, but it
> helps when there are merges".  The a-thru-f side branch in your picture,
> or any "culprit side branch that was merged" your algorithm finds in
> general, would eventually have a linear segment, and having x-o-x in the
> history fundmentally breaks "bisect"---your band-aid will not help.
>
> The whole idea behind using "bisect" to gain efficiency in isolating the
> issue depends on "Once you see a Good commit, you do not have to search
> beyond its ancestors", as it is to look for a single breakage that
> persists to the "Bad" commit you give, and as far as "bisect" is
> concerned, the breakage at A in your example is an unrelated breakage that
> did not persist through the history to the "Bad" commit H.

In the example above (after we know G is merged from e and F),
Those commits are old bad commit: A, B, a, b, ..., c, d (but we don't 
care about those old bad commits, we cared about latest bad commit that 
we met which is F)
It's possible that default git-bisect would jump to these old bad 
commits, and will finally find an old first bad commit
With bad-branch-first, it could help us to get away from the trouble 
that old culprit commit exist on feature1 branch for a period of time 
not fixed

Thanks
     --Shuang