Your example is in fact a good example why you should always rebase before merge. Only then would the reviewer have a chance to see the (potential) problem befo

Your example is in fact a good example why you should always rebase before merge. Only then would the reviewer have a chance to see the (potential) problem before it is merged. I'm not sure I understand why rebasing would confuse blame here. Have you tried it? If you rebase your "foo6" change on top of the "!foo3" change, the state of your branch will be exactly the state of your code base going forward. And that is the useful history to keep, not the order in which the actual keys were pressed.