> It’s an abuse of the newline character, which is meant to represent a new line

I also disagree with hard line wraps, but I wouldn't use this justification.

There isn't really such thing as a newline character. From ASCII we have line-feed and carriage-return characters intended for typewriters. There are conventions for how to interpret these as hard line-breaks in text, but they vary by platform. But even once you've picked how to represent your "new line" character -- does it denote a "line separator" (windows), or just a "line ending" (linux)? There's no real answer; just convention. (The difference often shows up when you consider whether you should leave one after the last line at the end of the document.)

We can't often look at ASCII or much of Unicode and ask "what is the meaning of this character" as if there's some canonical truth. IMO

Whichever character is used for a line ending/separator, it’s still wrong to conflate it with word wrapping.

In the general case, I agree (with the first part of your comment.)

But Linus makes a valid case for wrapping at the time of text entry instead of display: they want to wrap to 72 characters except in certain, specific cases, like when you have lines of output that should be represented verbatim.

Now, if you're using something like Markdown, this is no problem: triple-backtick the code block and let the rest of the regular text wrap automatically. But since kernel commit messages are strictly plain text only, that's not an option.

The way that line wrapping works out between github and regular git is a shame, because apart from that, since markdown tries to emulate plaintext conventions, it's not hard at all to write commit messages that look good both as plaintext and as markdown. (In this case, use the "original" markdown code block syntax of indenting with a tab or four spaces instead of using backticks.)

I disagree. There’s no valid use case. Users can word wrap lines at any width they want, easily.