Am 1/24/2011 11:30, schrieb Shuang He: > It's recursively applying bad branch first algorithm, not just constantly > stick to first parent. > Given this condition: > A -> B -> C -> D -> E -> F -> G -> H (master) > \ a -> b -> c -> d -> e / (feature 1) > \ x -> y -> z/ (feature 2) > start with H as bad commit, and A as good commit, if y is the target bad > commit. bad-branch-first algorithm will do it like this: > 1. In first round stick to master branch, so it will locate G as first > bad commit > 2. In second round stick to feature1 branch, then it will locate d as > first bad commit > 3. In third round stick to feature2 branch, then it will finally > locate y as first bad commit > So you could see, it's always sticking to branch where current bad commit sit Ok, so you explain what your algorithm does. But you did not illustrate your problem. The history above is ordinary, somewhat branchy, has *ONE* commit that introduces a regression, and *NO* commit that fixes the regression. But in your rationale you said something about "feature1 is fixed just a moment later after feature2 branch is created". How does this fit into the picture, where is the problem, and how does your algorithm solve it? -- Hannes -- 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