git bisect Vs branch

git bisect Vs branch

[Grégory Romé]

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

Re: git bisect Vs branch

[Santi Béjar]

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

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

Re: git bisect Vs branch

[Grégory Romé]

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

Re: git bisect Vs branch

[Johannes Sixt]

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

Re: git bisect Vs branch

[Grégory Romé]

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
> 

Re: git bisect Vs branch

[Daniel Barkalow]

[-- Attachment #1: Type: TEXT/PLAIN, Size: 1260 bytes --]

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

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

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*

Re: git bisect Vs branch

[Junio C Hamano]

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.