How to find and analyze bad merges?

["norbert.nemec" <norbert.nemec@native-instruments.de>]

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