Pavel Rappo <pavel.rappo@xxxxxxxxx> writes: > it for such merge commits produced automatically because of the > assumption that nothing bad can happen there. I do not think that assumption holds in the first place, though. A typical and often cited example is when one side changed a helper function's behaviour while the other side added new callers to the helper function, still assuming the original behaviour. In such a case there may not even be an textual conflict but the end results may be broken, and if the breakage is subtle, it may take weeks or months before somebody notices such a semantic mismerge. Your "review a conflicted-and-resolved merge on one integration branch once, and skip the re-review as long as the resolution is the same way as the original one when the same branch gets merged into another integration branch" is a neat idea (and the integration branches we have in our project are run more-or-less like that). But there, you'd need more than "both are cleanly auto-merged"; more like "both may have conflicted but they are resolved the same way" is what you are interested, no? Since at that point, your primary interest shouldn't be "does it cleanly auto-merge?" but "do these two merges do the same thing?", determining if a merge was created automatically becomes a problem you do not need to solve, or solving it would not further your true goal. If you have two integration branches A and B, and a topic branch T first gets merged to A and then after proving its worth it gets merged down to B, I wonder if you can verify somebody's merge of B into T by comparing the result with your "verification merge", which you preform locally and on a throw-away branch by using "git rebase --rebase-merges" or some mechanism, to replay the original merge of T into A on top of B (before the merge of T you are verifying).
