Re: git bisect Vs branch

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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@xxxxxxxxxxxx> 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



--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[Index of Archives]     [Linux Kernel Development]     [Gcc Help]     [IETF Annouce]     [DCCP]     [Netdev]     [Networking]     [Security]     [V4L]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux SCSI]     [Fedora Users]