help reverting a merge

help reverting a merge

[Justin Mattock]

(I'm not on the list, so hopefully this goes through).
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

when trying to revert this commit I get this:
git revert a03fdb7612874834d6847107198712d18b5242c7
fatal: Commit a03fdb7612874834d6847107198712d18b5242c7 is a merge but
no -m option was given.

then doing this I get this:

git revert -m 1 a03fdb7612874834d6847107198712d18b5242c7
Automatic revert failed.  After resolving the conflicts,
mark the corrected paths with 'git add <paths>' or 'git rm <paths>'
and commit the result.

how do I find out the commits in this merge to automatically
revert to find the problem that's causing this bug?


-- 
Justin P. Mattock

Re: help reverting a merge

[Jeff King]

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

Re: help reverting a merge

[Justin P. Mattock]

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

Re: help reverting a merge

[Justin P. Mattock]

First things first is I owe you a great thanks
for teaching me how to do a rebase.. :-)

took a while, and still a bit confusing
but I managed to do exactly what you
had written down.

bad thing is somehow the bisect came up
with no results. probably will do another bisect,
just to make sure things are in the right
direction, and the try the rebase again.

Again Thanks for the help/info on this.

Justin P. Mattock