On 2011/1/24 18:50, Johannes Sixt wrote:
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
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
Thanks
--Shuang
Thanks
--Shuang
--
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