Re: git bisect Vs branch

["Grégory Romé" <gregory.rome@maxim-ic.com>]

Thanks even if that's what scared me :)
The draw is very simple comparing to the reality (much more merge points) and 
rebase will require lot of conflicts resolutions but now I'm sure that's what I 
have to do.

Grégory

Johannes Sixt wrote:
> Grégory Romé schrieb:
>> 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''-
> 
> C" is the commit that merges upstream changes into your changes. You are
> saying that your changes alone (before the merge) are good, and that
> upstream before the merge is also good (since it doesn't contain your
> changes, it is good by definition, more or less). That indeed means that
> the merge commit is the first bad one; i.e., this is exactly the situation
> that the user manual describes.
> 
> You should do:
> 
>   $ git checkout -b tmp master   # master is at C"
>   $ git rebase origin/master
>   $ git bisect start tmp orgin/master
> 
> That is, you rebuild your history on top of origin/master in a linear
> fashion. (If you had merge conflicts in U', then you will see them again.)
> Then you bisect the linearized history. This will point you to the bad
> commit and you will understand what is going wrong.
> 
> With this new knowledge, go back to master (C") and fix the problem.
> 
> -- Hannes
>