Best Practices with code/build fixes post-merge?

Sometimes, I merge 2 branches that have deviated quite a bit. A worst-case example would be some API change. The topic branch (long-lived) may start using the old API. However, once I merge the topic back to master, that API no longer exists. As such, every place that introduces a usage of the old API will fail to build (but won't necessarily cause a conflict during a merge).

Concerning best practices, which of the following is better?

1. Make the fixes (which may be vast), smoke test, get a general feel
that everything is working on master again. Amend the changes to the
previous merge commit.

2. Make the fixes as in step 1, but instead of amending to the merge
commit, create a new descendant commit representing the changes.

Concerns I see with either choice:

1. Pros: Changes are atomic. Cons: merge commits are typically very
difficult to view, especially from logs. For example, `git log
--name-status` does nothing for merge commits, so it makes it
less-intuitive to get a good overview of changes.

2. Opposite of #1: Changes are not atomic (con), but it makes it very
clear that these changes were made "on top of" the merge (pro)

Is there a best practice here? What do each of you do as a personal preference or policy? Thanks in advance.