git bisect Vs branch

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...

Thanks, Grégory

(1) http://www.kernel.org/pub/software/scm/git/docs/user-manual.html#bisect-merges

On Thu, Oct 22, 2009 at 5:48 PM, Grégory Romé <gregory.rome@maxim-ic.com> wrote:

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

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:

Grégory Romé schrieb:

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

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:

On Fri, 23 Oct 2009, Grégory Romé wrote:

Alternatively, you could say that your testing procedure is to merge with your branch and check for the regression. Instead of bisecting U''-C'', bisect U'-C', but merge master (or rather, the first parent of the merge that started not working) before testing each commit. Pose the problem as upstream having a regression in that it doesn't work when merged with your code, and solve that problem with bisect.

But, before you start, verify that merging U'' and origin/master doesn't work; if it does work, you recently introduced the change that doesn't work with upstream, and it's probably a lot easier to find what you did that's not okay any more than what made it not okay upstream. That is, make C*; if it works, rebase your recent changes on it and debug that. This should have fewer conflicts and be easier than the full rebase, if C* actually turns out to work:

U'--o-o--C'
 \       |\
  U''-y-y--C''
   \     |
    -----C*--y-y

	-Daniel
*This .sig left intentionally blank*

Grégory Romé <gregory.rome@maxim-ic.com> writes:

So the breakage is about the feature you added on your tree, which neither of the grandparent upstream nor your direct upstream has. U' worked, C''^1 (i.e. immediately before you merged from your direct upstream at C'') worked, and C'' doesn't.

This happens when a commit in the upstream (either in your direct upstream or its upstream) changed the semantics of a function (or a variable's value) in such a way that it invalidates some assumption that your code has been relying on.

You can restate the problem into a slightly different form:

 - If I merge C' to my master (C''^1), it breaks;

 - If I merge U to my master (C''^1), it works;

 - Starting from (U = good, C' = bad) pair, find the first "bad" commit,
   where the badness is defined as "when it is merged to C''^1, it
   breaks".

The restated problem is "where in their code did they change something that breaks my code?"

You do not have to make a merge in the repository you are bisecting in. For example, I would try something along this line:

    $ git clone . ../test-build ;# make a build directory
    $ M=$(git rev-parse master^1) ;# before the latest merge
    $ U=$(git merge-base $M origin/master)
    $ git bisect start
    $ git bisect bad origin/master
    $ git bisect good $U

This will check out one commit between U and C' (that will include commits beetween B and C, as they are reachable from C' but not from U) for you to test. Since the condition you are testing is "Does the result of merging a commit to $M work?", you check exactly that condition:

    $ H=$(git rev-parse HEAD)
    $ cd ../test-build
    $ git reset --hard
    $ git checkout $M
    $ git merge $H
    ... do your testing here ...

And go back to the repository you are bisecting, and tell the result to bisect to continue:

    $ cd -
    $ git bisect good ;# or bad

And do the same for the next commit to be tested.

The result will tell you which commit in the upstream changed the semantics of what you were relying on under you, and by examining that change, hopefully you will know how to adjust your code to the new world order the upstream (re-)defines.