More seriously, it is quite hard to wrap text correctly after you submitted it. For example people add manual line breaks for structuring text and to separate things like quoted commands from the rest. It would be much more cumbersome to go back after a git commit to fix this, probably in multiple iterations until you get the intended presentation instead of just doing it right from the start.
Using a text editor to automatically embed line breaks doesn't fix the problem: embedding line breaks in text for formatting is wrong semantically. Hard line breaks should mean something. Now I can't reflow the text to display it on a web page in a normal font, because I can't be sure of which line breaks are meaningful, and which are formatting.
correctly in a plain text field?Text layout is a hard problem. It's why TEX (and its derivatives) is still so damned useful (and complicated).
Don't wrap lines with a four-space prefix (or whatever format is decided), wrap lines without one. Allow users to disable the wrapping if they prefer wrapped code. The prefix can be stripped at display time if you wish, so that code is left-aligned - actually, since the formatting isn't encoded in the log, only the semantics, users can configure the display as they please.
Possible handle lines beginning with - as lists and indent them correctly. If a message somehow breaks the format, do not accept it. This isn't TeX-level complexity.
When practical, of course.
In this case, git could simply give a "are you sure you want to commit with these long lines?" warning.