Re: How to find and analyze bad merges?

> "norbert.nemec"<norbert.nemec@native-instruments.de>  writes:
>
>> Thinking about a possible solution:
>>
>> Is there a way to re-do a merge-commit and diff the result against the
>> recorded merge without touching the working tree? This would be the
>> killer-feature to analyze a recorded merge-commit.
>
>    git checkout M^
>    git merge M^2
>    git diff M HEAD
>
> You'd have to resolve conflicts though.  If you want to skip that, I
> think you could still see some information if you said
>
>    git reset
>    git diff M
>
> to see the differences between the (unmerged, with conflict hunks) state
> in the worktree and M.
>
> (Remember to re-attach your HEAD after playing around like this.)
>
>> Am 02.02.12 09:16, schrieb Junio C Hamano:
>>>
>>> Bisect?
>>
>> This is not the point: My colleague knew exactly which commit
>> contained the bugfix. The trouble was finding out why this bugfix
>> disappeared even though everything indicated that it was cleanly
>> merged into the current branch.
>
> But that makes it a prime candidate for bisect: you know the good commit
> (the original bugfix), and you know that the newest version is bad.
> Bonus points if you have an automated test for it, in which case bisect
> can nail the offender while you get coffee.
>
> Or am I missing something?
>