[rpsw]

Overall agree with the sentiment, but I would add a more specific Bottom Line Up Front (BLUF) such as: "Fix test issues caused by non-breaking space character \xa0".

Tells me exactly what the problem was straight away, but I'm still free to choose to read more if I want to know more.

[Anon1096]

Yep this message is way better. And honestly, looking at the diff in github it is pretty obvious to me what has changed (and why really, since the only reason for a changeset to have a diff look identical is that non-visible characters have been added or removed).

So all I'd require is a good main message for history-search purposes. A short story about how you went to Narnia and came back to find the root cause of a bug isn't really relevant imo but I'm also not against writing it if you just want to vent in a PR description/commit's extended message.

[ninkendo]

Stories about how you went to narnia and back may be useful to a future contributor who finds themselves in narnia. This is very likely not the last time that an invalid byte sequence will show up in one of the source files in this tree, and if it happens again, it may be good to see the symptoms in the git log.

[master-lincoln]

This would be my ideal commit message as well. The rest of the commit body in the article is just how it was discovered. I don't think describing how one works belongs into a git commit message. Your message tells me why and which change was made, that's enough to me.

[nextaccountic]

I love this concept. I always begin messages with the most actionable or important thing at the top, and the rest that follows is the context. Respect the time of others and don't bury the lede

[SamuelAdams]

You see this all the time in business proposals. Executive summary at the top, typically 2-3 paragraphs max. Manager summary, 1-2 pages. Engineer detailed overview, 3-10 pages. Anything else is an addendum.