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

[Junio C Hamano <gitster@pobox.com>]

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.

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?

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?

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.