In a recent mailing list update, Linus Torvalds expressed frustration over passive voice in commit messages, urging developers to adopt a more active and clear communication style.

Linus Torvalds expressed frustration over the use of passive voice in merge commit messages, preferring active and imperative language instead.

He provided an example of how commit messages should be rewritten for clarity and consistency across the project.

Torvalds noted that while it’s not a major issue, it does add extra work when he has to rewrite messages to match his preference.

  • mox@lemmy.sdf.org
    4·
    1 month ago

    I read his message. He didn’t seem grumpy or frustrated to me; just encouraging folks to use a certain style that’s already in wide use, for reduced noise and better consistency.

    • Otter@lemmy.caEnglish
      3·
      1 month ago

      The message:

      "I try to make my merge commit messages be somewhat “cohesive”, and so I often edit the pull request language to match a more standard layout and language. 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. I generally do it as I read through the text anyway, so it’s not like it makes extra work for me.

      But what does make extra work is when some maintainers use passive voice, and then I try to actively rewrite the explanation (or, admittedly, sometimes I just decide I don’t care quite enough about trying to make the messages sound the same).

      So I would ask maintainers to please use active voice, and preferably just imperative."

      Giving an example of a bad commit message, Torvalds provided this example: “In this pull request, the Xyzzy driver error handling was fixed to avoid a NULL pointer dereference.” He believes this should have been written as follows: “This fixes a NULL pointer dereference in …”

      • remotelove@lemmy.ca
        2·
        1 month ago

        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.)