Good code or not, if he doesn't agree with the reason to merge it, why merge it?

Because the code is OK, but the _rationals_ in the commit message (union aliasing is bad) are not.

This is for history. If someone, later, say: "We should use union aliasing to fix this", someone would argue "No, we shouldn't because we already states _there_ that union aliasing is bad".

You can't consider a such amount of code like the kernel one without its commit history.

Here Linus explain why union aliasing is not "bad" per see, but considered "bad" because the C standard say so and he clearly explain standards are not holy book and compiler implementation is as important (something he always states).

But if he doesn't agree with the commit message, then asking for an altered PR with a different commit message is surely the way to go. Having to trawl the mailing list for maybe-happened-discussions seems like a stupid way to organize things. Maybe I just don't know how they structure the kernel development and documentation.

Presumably, there was a follow-up discussion.