“After 20 years coding I just realised, commit messages are pointless”
twitter.com
twitter.com
Look, I work in a "squash commits, messages are for detailing tickets" place. I can understand not liking commit messages (although you really should, they are comments for your changes!). But this whole idea of "it's okay to have completely awful code because you are still growing :)" is how you get permanent spaghetti that costs absurd amounts of money to fix. There is nothing more permanent than a temporary solution, and deluding yourself into thinking uncommented, messy, untested, godawful code is acceptable "for now" will never end.
Maybe I could excuse this if it was just commit messages being automatically the ticket names or at least some idea of what is happening. Making it "commit" is a horrendous idea. Why are you sabotaging your future self by not describing what you are doing in a commit message? Just to save 10 seconds per commit via your script?
By the time I came along, the consensus among senior devs was that the entire project was a loss and we'd have to start from the ground up on the next project.
They're still shipping the same showstopper bugs nearly ten years later.
If you want your project to last more than a couple of years, or if you want to use it as a base to build other projects on, you should care about code quality. Don't try to implement an entire game engine on the back of some shit an intern threw down in a weekend and now you're too scared to touch it
If you want your project to last more than a couple of years
It took them a good five years to announce the sequel. Presumably because they had to scrap the entire bespoke game engine and redo everything from scratch. When I was there it was accepted as fact that the only path forward for a sequel was to start from zero and build a whole new engine because it was so bad.
I could go on for days about it, but I think the best example was the Character class. At one point it was over 27000 lines of code split across 5 separate files. Characters took up an astonishing fraction of the total cpu time, especially considering that you'd have a dozen or two characters in a world with thousands or tens of thousands of other entities.
I saw a startup that was so tech debt-heavy that they couldn't move. They were stuck daily patching nasty code.
Engineers who don't care about code quality are like coworkers with messy desks that spill onto yours.
They can't literally be showstoppers if they are still in business.
Still, nobody accepts that level of crap any more when building, say, a bridge. They used to, back in the Victorian age, until they figured out what worked (the great victorian era bridges still in use are the ones that didn't fall down -- a survivorship bias).
I think the fact that we only demand reliability from aircraft, trains, (some) med devices, spacecraft and banking shows how unimportant most software is. Most software will never need the level of reliability of the domains in my previous sentence, but sheesh, the needle needs to move in that direction.
Totally unacceptable issues that have been around basically the entire life of the game. Their success is complicated, but in general the loyal players became conditioned to accept these bugs, while new players would hang out for a few weeks until their vehicle explodes and they lose days of progress for the nth time. Player turnover was huge, but they have a fairly large core of players who just deal with it.
My problem is often perfectionism gets in the way of shipping where I'll spend too much time on minutia. At work, coworkers are more liberal in tech debt accumulation because there's a drive to ship maximum impact that can be quantified.
I also like having the story id as part of the commit message so merge requests can be connected to stories. It gives a better overall picture of what took place.
And how do you locate the commit of interest? I usually search the commit messages…
It is what I usually do, not a solution to all problems :)
My commit messages look like small essays (after the first summary line, of course), so I think we agree.
No one will answer what to do if you have no idea of what’s in the code (bc it’s old or you’re new to this repo).
Basically, this idea is a failure but some people think it’s neat so they’ll come up with contrived justifications that make no sense.
I do a fair amount of git blaming on my own code and I find that my years-old messages do help me understand the purpose of old code.
Instead of writing a summary of my commit into the commit message subject, I try to use related keywords, tags, and references.
Usually it starts with a section prefix indicating what part of the code is touched. "UI:" is a common example. After a short sentence containing the most important keywords, I add bug tracker IDs to issues related to my commit.
The goal for me is to find a previous change as quickly as possible when something related occurs in the form of a bug or a feature.
It's also a part of the storytelling of a good PR. I don't force anyone to go back and rename commits or anything (and I don't squash either; I'm happy with --first-parent and other tools), but it's a lot faster and nicer sometimes to review a PR commit-by-commit from someone who put the time into telling a useful story in their commit documentation.
Interesting code that requires context should live in a discussion and be pointed out in the PR body.
Since the artifact of a PR is a squash-merge commit back to mainline and the PR allows for very rich discussion and automated checks and annotations, it makes no sense to add those details into messages that will get lost.
If you DON'T use PRs/MRs for code management (though you really should!!!), then commit messages are EVERYTHING.
and I've been coding for 39 years, for whatever use that metric is. (none- doing something for a long time doesn't mean you're not wrong about how you're doing it.)
If you are the kind of developer who works locally for weeks and then pushes 1 gigantic "work" commit, you are probably annoyed by all sorts of processes.
If you are the kind of developer who commits every 5 minutes, these messages can serve as an excellent near-real-time indicator to the rest of the team about where you are working and the progress so far. For PRs that go beyond 30 days, these commit messages are also for me. I can't keep everything in my head for the larger features.
Which I kinda agree with. The attention that commit messages deserve is highly variable. I’ve been meaning to write a script that will generate a commit message based on the files changed. “added models.py, edited settings.py”. This so I can just blast commits locally but still have some info in the message. When I merge, I squash and make one good message.
(If I really get nerdsniped, I’ll have the message based on the code. Like “edited User.login()”)
I don't typically squash these commits, but if I do need to dig deeper that --first-parent in git blame or git bisect it is easy enough to build an ignorerevs file including all the "wrenchs". Sometimes that history has been specifically useful in frameworks that are very scaffolder/package management heavy with infrequent updates that touch a lot of scaffolding and package. It can be handy to glance at the last big update PR for a partial script list reminder.
You can get that information with the git log --name-status parameter.
One trick I've learned in 10 years coding is not to waste time on Twitter. Instead, every time I push a commit, I also push a tweet that just says "Tweet!". Tweet!
It commits every 1 second. Echo to the file current-task to change the commit message from that point onwards. If you have no changes, the commit is a no-op.
#!/bin/bash
while true; do
sleep 1
(git status -z;
git add . && git commit -m "autocommit $(cat ../current-task)" ; git push);
done > autocommit.log 2>&1
I use a bare GitHub repo in the shared folder in virtual box with a git hook to trigger a build in the virtual machine.
See here
Thank you to @levelsio for just replying to the Tweet, my notification tab in Twitter is now laggy and broken :)
If you read the other replies I dropped into the tweet there is a little more context and I was half joking. It's for vanilla projects but TBH, my projects that produce the highest amount of profits actually have the worse code etc and worse commit messages, with no PRs. But hey lets all keep doing what we are doing.
Anyway just wanted to tell you all that this command is now even more awesome, it's now `alias g='git add . && git commit -m "x" && git push origin main'` in my bash profile, so I just run "g".
Why "g" you may ask? Because I'm a G.
Okay I'm just joking, it's for git ofc, but even shorter. Whoop.
p.s. reason deployments are so fast, it because I'm using Vercel. Currently shipping around 15 times a day to production woooooo.
git commit --allow-empty --allow-empty-message -a
Then again, if commit messages are pointless, then why bother using version control rather than automatic backups?
And sometimes, someones wins the lottery and discovers a whole new way.
Carry on, I won't judge you, the universe will. And I'm just reaping knowledge out of it. For free and painless. Whatever the outcome is.
Commit messages are a summary of what's inside.
The description area is for the test plan to prove your code was tested and doesn't break things beyond automated lints and CI/CD testing.
> Until it starts generating PROFIT, anything else like: clean code, unit testing etc, makes zero sense. And also for the record, whenever I'm trying to figure out where something went wrong, commit are not the thing I look at, it's the code changes in the commit.
Others have commented on how this reasoning affects the code itself, but I'll ask something different: what about the other 90% of the time, which will be spent on maintenance? How will someone find changesets of interest among others, without looking through the contents of every single commit due to them having no messages, thus removing any chances of them finding the right one based on the message and short circuiting the process? How will they figure out what the other developer was even thinking or trying to do, if the code is decently written, but structurally just odd?
After all, your code comments themselves can have references to requirements in whatever change management system you use (e.g. Jira), or even snippets of business requirements and such for what the reasoning is behind that particular code being written in the way it was (code explains HOW, requirements explain WHY), but in my experience more often than not it won't have all of that, and instead you'll only be able to conduct code archeology more successfully by tracing back through commit messages (which ideally will start with an issue identifier), or at least merge/pull requests, which will bring you to the original requirements for any given change, no matter how many years back it was made.
Seeing that issue VMP-14221 is related requirements wise to VMP-5661 that was implemented 5 years back and being able to find an erroneously renamed parameter thanks to some commit messages being noticeable in a sea of others (like "VMP-5661 refactor MyBusinessObject to work with VMK links") in that time frame and then inspecting whether the contents of those particular ones match up with what they say they should do, might just make maintenance more tolerable.
The only set of circumstances where I think that'd be useless is personal projects, where you'll be the only one working on them and perhaps don't particularly care about the viability of understanding how the code evolved over time, if the projects aren't commercial in nature. Though other times, when you start writing of a commit message, you realize that it would be better to split your changes up in multiple atomic commits, in case you mess up and reverting something might be necessary.
Overall, with everything else being realistic (passable but not ideal circumstances), personally I'll take commit messages over no commit messages, ideally with issue identifiers (implying change management systems of some sort are in place).