I think including all review/PR comments in the merge commit is overkill, it already tends to be hard to read the history with git log -p because the long, not-for-console formatted text that gets included from the opening post.

With review comments I mean only the ACKs (adjusted title)

Example:

commit 67e54064294326b8fba1c420aaa1b8afb084bf25 (HEAD -> pull/15463/local-merge)
Merge: abd914ed34 643eba0aa2
Author: MarcoFalke <[email protected]>
Date:   Fri Mar 22 12:33:22 2019 -0400

    Merge #15463: rpc: Speedup getaddressesbylabel
    
    643eba0aa2 rpc: Speedup getaddressesbylabel (João Barbosa)
    
    Pull request description:
    
      Fixes #15447. Same approach of #14984, this change avoids duplicate key check when building the JSON response in memory.
    
    ACKs for commit 643eba:
      ryanofsky:
        utACK 643eba0aa262ead636d5de18ced31b6f166ec033
      MeshCollider:
        utACK https://github.com/bitcoin/bitcoin/pull/15463/commits/643eba0aa262ead636d5de18ced31b6f166ec033
    
    Tree-SHA512: ee0941130ada600171d36cf69219921ab2fa044402cedc57cdf73bdb23499555c53bc076d65ef117d0a8f5cbc5381a49e40d945766796241936a701678b72ab6

With review comments I mean only the ACKs (adjusted title)

Oh that does sound good!

see merge commits for a live example:

• 6852059 (ACK includes the full line, with trailing comment)
• 8a8b03e (ACK pulled from issue comment and review comment)

Nice! utACK fa1c073

Concept ACK

Concept ACK

Nit: If I'm reading the code right also NACK:s will be included under the heading "ACKs for commit […]". If that is intentional then perhaps change heading to "ACK/NACKs for commit […]" to clarify?

@practicalswift No, it would only show up if you NACK+the commit id, which is rarely (never) done.

Concept ACK

@MarcoFalke Thanks for the clarification. I missed the and head_commit in l :-)

utACK fa1c073 (nit: a run with your yapf script would make it even more beautiful :-))

utACK fa1c073