Re: help reverting a merge

["Justin P. Mattock" <justinmattock@gmail.com>]

On 11/30/09 00:13, Jeff King wrote:
> On Sun, Nov 29, 2009 at 03:24:09PM -0800, Justin Mattock wrote:
>
>> I've done a bisect on a problem with the kernel,
>> and am a bit confused on what to do. i.g. the
>> results are showing this:
>> a03fdb7612874834d6847107198712d18b5242c7 is the first bad commit
>>
>> [...]
>>
>> how do I find out the commits in this merge to automatically
>> revert to find the problem that's causing this bug?
>
> There is some discussion here:
>
> http://www.kernel.org/pub/software/scm/git/docs/user-manual.html#bisect-merges
>
> Basically neither merged branch was buggy on its own, but together they
> have a bug.  You can try rebasing the two sides of the merge into a
> linear history, and then bisecting on that:
>
>    # order doesn't matter here, but rebasing 12e0933 on top makes more
>    # sense since it has many fewer commits between it and the merge-base
>    # (and you'll need to fix up conflicts manually, so the smaller the
>    # rebase the better)
>    git checkout 12e0933
>    git rebase 202c467
>
>    # to be safe, confirm that the rebase result shows your bug;
>    # we know that 202c467 doesn't have the bug, or we would not have
>    # bisected to the merge commit before
>    test test test
>    git bisect start
>    git bisect bad HEAD
>    git bisect good 202c467
>
> which should give you the specific commit on the side branch where the
> breakage occurred.
>
> This has been discussed as a technique before, and I have a feeling in
> the back of my mind that maybe there was talk of having git-bisect help
> with this case, but I don't think anything ever came of it. Christian
> (cc'd) would probably know more.
>
> -Peff
>

ahh cool..
I'll have a read on this in the
morning(late now)and see if I can do this
to find the bug.(keep in mind might take
some time i.g. not good at using git,
but am willing to learn a thing or two).

Justin P. Mattock