From: Grégory Romé Date: Fri, 23 Oct 2009 07:09:29 GMT Subject: Re: git bisect Vs branch Message-ID: <4AE156A9.9060809@maxim-ic.com> In-Reply-To: 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é 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