Re: git bisect Vs branch

From: Johannes Sixt <j.sixt@viscovery.net>
Date: Oct 23, 2009, 08:34 UTC
Message-ID: <4AE16A82.1010103@viscovery.net>
In-Reply-To: <4AE156A9.9060809@maxim-ic.com>

Grégory Romé schrieb:

Show 12 quoted lines

> 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