From: Grégory Romé Date: Fri, 23 Oct 2009 09:24:21 GMT Subject: Re: git bisect Vs branch Message-ID: <4AE17645.2000408@maxim-ic.com> In-Reply-To: <4AE16A82.1010103@viscovery.net> 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 >