Real developer's commit messages are all “Oops”.
this post was submitted on 08 Oct 2024
136 points (90.5% liked)
Programming
17138 readers
563 users here now
Welcome to the main community in programming.dev! Feel free to post anything relating to programming here!
Cross posting is strongly encouraged in the instance. If you feel your post or another person's post makes sense in another community cross post into it.
Hope you enjoy the instance!
Rules
Rules
- Follow the programming.dev instance rules
- Keep content related to programming in some way
- If you're posting long videos try to add in some form of tldr for those who don't want to watch videos
Wormhole
Follow the wormhole through a path of communities [email protected]
founded 1 year ago
MODERATORS
maybe this will work
...
...
...
linting and unit tests
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"
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 …
That's actually helpful, thanks
depending on the time of day my commits range from war and peace to 'jfc here is just the message "yeah" for the next twenty commits because the client keeps requesting stupid ass decisions".
As the day goes on
fixup=fixup -fuck
fuck
bleh
some bug squashin
implement stuff
Fixes configuration issues, and improves the UI for setting it up
And here it is in the kernel contribution documentation.
Simple example:
- bad: ~~Added foo interface.~~
- good: Add foo interface.
So the commit says what applying the patch will do, not what you worked on.
This has been the recommendation and the way to do it for decades everywhere I've been too.
good: Add foo interface.
Another commit style is summarizing what a commit does. In this case it would be someting like:
Adds foo interface.
I think this style is more in line with auditing code.
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.
Honestly I've never thought about it this much. I'll have to make an effort to stop writing in past tense.
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 ..."
Usually just start with the verb.
"fix a NULL pointer dereference in ..."
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 ..."
This is the language I use, once I started I never looked back.
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.
But it's Linus so everybody likes to think everything he says is blunt and crass.
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.)
You still should use condoms.
When I see my Dr. or when I talk to other engineers?
Agreed this is essentially a style guide.
When I do commit, I write up the title of what I did, and describe it, and then use periods for related commits. Just easier.
There are much smaller projects that ask for more from commits/merge messages. This is a normal ask
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 excuses~~ explanation 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. 😅