TIL I write better commit messages in my hobby projects than some Linux maintainers
“fix”
I thought conventionalcommits.org was very well known.
I made my company use it and now it’s so much easier to navigate git history. We also get automatic, humanly readable changelogs for free.
A while ago, I wrote a tool to generate change logs from commit messages. It grabs all commits from a tag to the previous tag, and collates them into a Keep A Changelog format.
An unintended consequence is this is that my commit messages are in keepachangelog format; the tool just groups messages by type and adds the version and date decoration, and then inserts the text at the right place in the file.
It’s fantastic. Because I know the commit messages will end up in the changelog, it encourages me to describe the commits in terms of:
Adds blah blah Changes blah blah Fixes blah blah
Anything that doesn’t start with a keyword is discarded, so I can still jot notes in the commit, but by far the biggest benefit is that it’s completely broken me of the habit of reiterating the code change that I committed, and write the reason for the commit in descriptive language.
Having a little reinforcement such as tooling can do wonders for building good habits.
Postscript I don’t know if anyone cares about this – it’s pretty specific to my workflow, but if you want to see the tool, it’s just a shell script. The only non-standard tool it needs is ripgrep. You pipe some set of commit logs to it, and it collates them into sections. In the repo is a very Mercurial+bookmarks function that’ll automatically grab and generate a section for the latest bookmark. But it boils down to something like this:
hg log -vr v0.0.4:v0.0.3 -P v0.0.3 | changelogI only use git when I absolutely have to, so I don’t know what the equivalent command for that is; but here:
- I use
-vbecause I want the full commit. For a given commit, if there are multiple changes, I put each on its own line. Both git and hg only print the first line of each commit message by default, so to get all lines of commit log messages with Mercurial,-vis needed. -r v0.0.4:v0.0.3generates logs in reverse chronological order, from the commit with bookmarkv0.0.4to the one with bookmarkv0.0.3. This should work with tags, too.-P v0.0.3prunes thev0.0.3commit, so that its message doesn’t get included with thev0.0.4log entry.
- I use
git commit -am "no u"guy commit -m “fixes”
I’m not a real programmer. What does this means?
When developers commit source code to a shared repository (for integration in software people like us use), they have the often-squandered opportunity to summarize the changes they are submitting. Linus (rightfully) thinks this opportunity should be leveraged more appr9opriately and more often, with more quality.
Worth noting that this is stored in the repository alongside the code changes and can be referenced in the future if someone is trying to understand that code or fix a bug in that code.
For large projects spanning long periods of time sometimes the best way to find a bug’s cause is to scour the projects history to find out which commit caused the bug to appear, and if that commit doesn’t have a good description you’re unnecessarily disadvantaged when trying to find out why it caused the problem or what assumptions were going into the original code.
Trying to figure out if that typo was intent9ional or not.
Nope I’m just awful.
If you’re smart, you’ll make good commit messages in any commit, no matter how small and personal the repo. Because one day you’ll have no idea what that change was about and why and a small note will make it much easier to figure out.
You change some code and send it in, you add a cover letter explaining what you did and why. The Linux guy wants you to write more detailed cover letters when you do.
edit: wrote this before reading the article. he actually just wants people to write using active voice instead of passive.
Aww, more personalized
COMMITMSGs?!..That’s wholesome.
Linus Torvalds wrote git in two weeks. In a CAVE. With SPARE PARTS.
One of the things I hate about merge-based Git workflows is git makes a default
Merge 123234234 from user/dave/fsdfmessage which:a) Is shit - it contains zero useful information (what’s in the change??) and contains information you explicitly don’t care about (the temporary branch name the author happened to use). a) Makes people think they are supposed to use that message.
It would probably be better if the default message was blank. But also squash & rebase is generally better anyway and it avoids this problem entirely.
Is it imperative or bare infinitive?
The advice I stick to is letting your commit message follow “applying this commit will BLANK.” So like “Fix error when blah” as opposed to “fixes error when blah”
