Re: git bisect Vs branch

From: Daniel Barkalow <barkalow@iabervon.org>
Date: Oct 23, 2009, 16:31 UTC
Message-ID: <alpine.LNX.2.00.0910231137290.14365@iabervon.org>
In-Reply-To: <4AE17645.2000408@maxim-ic.com>

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*