Re: git bisect Vs branch

["Grégory Romé" <gregory.rome@maxim-ic.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:
> 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