Re: [RFC] Add bad-branch-first option for git-bisect
On 2011/1/24 18:50, Johannes Sixt wrote:
Show 26 quoted lines
> 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