Honestly, makes sense, the active voice version is just... more efficient and easier to parse quickly.

Weird the example he gave isn't imperative, which I think would be "Fix a null pointer dereference in ..."

Usually just start with the verb.

"fix a NULL pointer dereference in ..."

It's not a big deal, and often it's literally just about whitespace so that we don't have fifteen different indentation models and bullet syntaxes.

Any in many ways, that is the way engineers should speak to other engineers when analyzing a problem.

If two or more people can actually share a common goal of finding the best solution, everyone involved should be making sure that no time is wasted chasing poor solutions. This not only takes the ability to be direct to someone else, but it also requires that you can parse what others are telling you.

If someone makes something personal or takes something personal, they need a break. Go take a short walk or something. (Linus is a different sort of creature though. I get it.)

TBH, this is part of the reason I chose my doctor (GP). She is extremely direct when problem solving and has no problems theory-crafting out loud. Sure, we are social to a degree, but we share many of the same professional mannerisms. (We had a short discussion on that topic the other day, actually. I just made her job easier because I give zero fucks about being judged for any of my personal health issues.)

This indicative mood is something I would send back for correction or correct myself where I am the maintainer. However I understand that although this is pretty consistent through FOSS, it is not a settled matter especially in corpo-land. Most important is that it is consistent within a project. See many differing views here on Stackoverflow, noting the most popular answer though is imperative as Linus requests.

you put a dot after commit msg?

Oh I read it as the singular, as in "a real developer's ___"

I always thought of the "how" being better explained by the code itself where you can see string.replace(" ", "\ ") as the actual fix while the message says the "why".

I would still have "Fix a bug where strings containing whitespace break CSVExporter" as my go to message.

I guess our viewpoints are different based whether we want the commit messages to represent tasks or changes. They both have their uses of course. Looking at changes to a file to know what people have done to it is better with a "changes" type message but looking at the history to check "did we actually complete this or was it just marked as completed in the issue tracker?" is better with a task based message.

Task management where every issue is put on a ticket and tracked would my type of messages obsolete but at my current company theyre very useful.