Shuang He <shuang.he@xxxxxxxxx> 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. -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html