Re: git bisect Vs branch

From: Grégory Romé <gregory.rome@maxim-ic.com>
Date: Oct 23, 2009, 07:09 UTC
Message-ID: <4AE156A9.9060809@maxim-ic.com>
In-Reply-To: <adf1fd3d0910220950s50ccf8efwda891374e6480a30@mail.gmail.com>

Thanks Santi but I have a problem, due to the fact that the commit which has an impact on my code is in origin/master or first-origin/master

When bisect checkout a commit from those branch I have none of my own 
modifications... So I can' test if my code is good or bad excepted if I can 
merge my commits in the bisect branch...
                                                     ᐁ
first-origin/master  *---A---------B----------------o------C-
                           \         \                       \
origin/master              ----------B'----------U-----------C'-
                                       \           \           \
master                                 ------------U'----------C''-

I generalized the problem but I can give a real example. My problem concerns an Linux USB driver for MIPS based SoC. first-origin is the official kernel repository and origin/master is the MIPS repository.

Cheers! Grégory

Santi Béjar wrote:

Show 31 quoted lines

> On Thu, Oct 22, 2009 at 5:48 PM, Grégory Romé <gregory.rome@maxim-ic.com> wrote:
>> Considering the following story what is the method to find the regression
>> with bisect?
>>
>> I cloned a git repository (origin) which derives from another one
>> (first-origin). A merge is done from first-origin to origin at each stable
>> release (identified by a tag).
>>
>> first-origin/master  *---A---------B-----------------------C-
>>                         \         \                       \
>> origin/master              ----------B'----------U-----------C'-
>>                                     \           \           \   master
>>                           ------------U'----------C''-
>>
>> Now, after that I merged C' I fixed the conflicts and compiled without error
>> but I have a regression. It could come from any commit between B and C or U
>> and C', and I need to modify my code to correct the issue.
>>
>> I would like to find the commit which introduce this regression by using git
>> bisect but as the history is not linear it is not so easy (1). It though to
>> create a linear history but I have no idea how to proceed...
> 
> You just have to proceed as normal, but you may test more commits than
> with a linear history.
> 
> The only problem is iff the culprit is a merge commit (as in the
> user-manual chapter you linked). And the "problem" is to know where
> exactly in the (merge) commit is the bug, but not the procedure.
> 
> HTH,
> Santi