Re: git bisect Vs branch

[Junio C Hamano <gitster@pobox.com>]

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

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

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.