Re: git bisect Vs branch

[Johannes Sixt <j.sixt@viscovery.net>]

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