From: Shuang He <shuang.he@intel.com>
Date: Mon, 24 Jan 2011 11:05:09 GMT
Subject: Re: [RFC] Add bad-branch-first option for git-bisect
Message-ID: <4D3D5CE5.4050108@intel.com>
In-Reply-To: <4D3D5989.50903@viscovery.net>

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