From: Johannes Sixt <j.sixt@viscovery.net>
Date: Mon, 24 Jan 2011 10:50:49 GMT
Subject: Re: [RFC] Add bad-branch-first option for git-bisect
Message-ID: <4D3D5989.50903@viscovery.net>
In-Reply-To: <4D3D54D3.7040801@intel.com>

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