How to find and analyze bad merges?

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