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.
Upd
Fix
Upd
Fuck
Updated file1
Fuck
Fix
Updated file2
Merge remote-tracking branch other-user1-feature
Fix after merge
Upd
Revert “Merge remote-tracking branch other-user1-feature”
Revert “Revert “Merge remote-tracking branch other-user1-feature””
You head him boys! Users of passive voice should be puched in the face!
Hey, I was wondering if you can update your commit with a punch in the face, if possible? No pressure thanks for contributing!
Linus Torvalds expressed frustration over the use of passive voice in merge commit messages, preferring active and imperative language instead.
Things To Care About, vol 147, 2nd edition
I like good commit messages that use less words but still give the full picture. If something hacky was done then a comment is better. I like mine with imperative voice since it avoids writing a prose.
“Fix a bug where when doing x then y happens”
“Add setting to control x”
Knowing you fixed a bug is minimal information and usually covered by an issue reference in professional software development. I’d prefer to see the commit describing what the fix is actually doing to fix the bug.
Right until the reference breaks. Ask me how I know.
I really don’t like starting with “fix.” You can just describe it without saying “fix” most times.
- Fix
Strings containing whitespace - Escape
Strings containing whitespace inCSVExporter
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.
I basically stole your comment but made a worse version. On this note, though, there’s sometimes value in using words like “fix” or other kinds of tagging or consistent formatting in the sense that you can do a meta-analysis of the repo history to look at trends (like the ratio of fixes to feature work) over time.
Issue tracking software obviates that, somewhat, but having that info embedded in the repo history lets you go further and look at which files have the most fixes etc.
Existing tools out there sometimes do this exact thing, but it can be manually done as well
- Fix
Real developer’s commit messages are all “Oops”.
maybe this will worklinting and unit tests
Love a good commit message. I wish I could say what we perceive as “good” is instead thought to be “normal”, but we aren’t there yet I guess.
If the word “imperative mood” is hard to grasp, this is what I do. I just finish this sentence in less than 50 - 75 words, length depending on consensus.
This commit will …
Add more details in the body if needed.
This sort of style extends to PRs/MRs as well.
This PR/MR will …
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.
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 …”
Honestly, makes sense, the active voice version is just… more efficient and easier to parse quickly.
But it’s Linus so everybody likes to think everything he says is blunt and crass.
Linus is a scary man and seems really hard to work with
The fact that Linux blossomed anyways goes to show his talent
Linus Torvalds: creator of Linux and Git, and hero to all English teachers everywhere!
So, uh, I have a colleague who studied linguistics, and when I explained to her that we write commit messages like that, her reaction was basically: What the fuck, why?
My explanation wasn’t as sharp, as I didn’t call it “imperative” but rather just “infinitive”, which got me the immediate backlash that it’s not a sentence then, so why do you put a dot behind it?
She did accept my
descriptivist excusesexplanation that we write it that way, because it’s terser, but I know it didn’t sit well with her.
Will need to see what her reaction is to commanding the repo. 😅you put a dot after commit msg?
Yup. Commit messages are often shown in truncated form, which is when the dot helps to know whether you’re seeing the whole message or not.
Well, and every so often, I’ll use the commit message to document why a change was made, which requires multiple sentences. Then the dot just serves its usual purpose of separating sentences.
