How to find and analyze bad merges?

> a colleague of mine happened to produce a bad merge by unintenionally
> picking the version of the remote branch ("R") for all conflicting
> files. Effectively, he eliminated a whole bunch of bugfixes that were
> already on his local branch ("L").
>
> Obviously this was a mistake on his side, but hey: everyone makes
> mistakes. The real problem is to find this problem afterwards,
> possibly weeks later, when you suddenly realize that a bug that you
> had fixed suddenly reappears.

> "norbert.nemec"<norbert.nemec@native-instruments.de>  writes:
>
>> a colleague of mine happened to produce a bad merge by unintenionally
>> picking the version of the remote branch ("R") for all conflicting
>> files. Effectively, he eliminated a whole bunch of bugfixes that were
>> already on his local branch ("L").
>>
>> Obviously this was a mistake on his side, but hey: everyone makes
>> mistakes. The real problem is to find this problem afterwards,
>> possibly weeks later, when you suddenly realize that a bug that you
>> had fixed suddenly reappears.
>
> Bisect?

>> 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.

> Hi there,
>
> a colleague of mine happened to produce a bad merge by unintenionally
> picking the version of the remote branch ("R") for all conflicting
> files. Effectively, he eliminated a whole bunch of bugfixes that were
> already on his local branch ("L").
>
> Obviously this was a mistake on his side, but hey: everyone makes
> mistakes. The real problem is to find this problem afterwards, possibly
> weeks later, when you suddenly realize that a bug that you had fixed
> suddenly reappears.
>
> A "git log" on the whole repository shows both branches R and L.
> A "git show" on the bugfix commit shows the bugfix as you expect it.
>
> BUT:
> A "git log" on the file itself shows neither the problematic merge nor
> the bugfix commit. Git considers the merge of this file trivial because
> the content is identical to that of parent R. Therefore, whatever
> happened on branch L is not considered relevant history of the file.
>
> FURTHERMORE:
> A "git show" of the merge itself does not show the conflicting file
> either. Obviously, "git show" on a merge decides which files are
> relevant not based on conflicts but based on resolutions.
>
> To sort out what happened, you first need to have a suspicion and then
> dig fairly deep in the manuals to set the correct options to show what
> happened.
>
> I think, both "git log" and "git show" should by default be a bit more
> conservative in hiding "insignificant" merges:
> * In "git log" a branch should only be hidden if it never touched the file.
> * In "git show" a merge should display all files that did have a
> conflict independent of the resolution. (I am open to discuss whether
> auto-resolvable conflicts should be displayed by default. Non-trivial
> conflicts definitely should)
>
> Greetings,
> Norbert
>

> "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?
>

> To be yet more precise:
>
> My complaint is that you need this kind of sledge-hammer solutions to
> analyze the situation. I, as an semi-expert with git did manage to find the
> problem without even having to resort to bisect or manually redoing the
> merge. My complaint is about the perspective of the medium-experienced user
> who is completely puzzled by the fact that a
> "git log <filename>" silently skips the critical merge commit.

> David Barr wrote:
>
>> Do the -c --cc or -m flags for git log help in this case?
>> They alter the way merge diffs are presented, as described under Diff Formatting
>> in the git-log(1)  man page.
>
> I suspect Norbert was running into history simplification, so the --full-history
> flag would be the relevant one.

>> See the thread [1] for a few relevant side-notes.
>  >
>  > [1] http://thread.gmane.org/gmane.comp.version-control.git/188904
>
> As I understand this thread, the user only requested all commits that
> "modify a file". Our merge-commit strictly speaking did not modify the
> file but simply kept one of the versions, completely swamping all
> modifications from one branch. Exactly the case that is still not
> covered by --full-history.

> On Thu, Feb 2, 2012 at 10:17 PM, Norbert Nemec
> <norbert.nemec@native-instruments.de>  wrote:
>> To be yet more precise:
>>
>> My complaint is that you need this kind of sledge-hammer solutions to
>> analyze the situation. I, as an semi-expert with git did manage to find the
>> problem without even having to resort to bisect or manually redoing the
>> merge. My complaint is about the perspective of the medium-experienced user
>> who is completely puzzled by the fact that a
>> "git log<filename>" silently skips the critical merge commit.
>
> Do the -c --cc or -m flags for git log help in this case?
> They alter the way merge diffs are presented, as described under Diff Formatting
> in the git-log(1)  man page.