“After 20 years coding I just realised, commit messages are pointless”(twitter.com)
twitter.com
“After 20 years coding I just realised, commit messages are pointless”
https://twitter.com/ashleyrudland/status/1615011065611358211
43 comments
At 3 AM, I need to scroll through a hundred commit messages to find the three that might have caused a problem. Paging through a hundred browser tabs of discussion is a lot more to read, assuming they still exist and weren’t discarded during a Jira migration or something. I assume commits are more durable and better reviewed than anything else.
But the scrolling and search for context would happen regardless, and non-technical users are more likely to contribute context into Jira or a GitHub PR than submit Git commits. better than searching through email!
I think the value of a commit message is directly proportional to the amount of discipline you have placed into the contents of each commit.
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.
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.
The Tweet is kinda hyperbolic. Commit messages are pointless for him in his current context. “ This is a new revelation for me on indie projects not for teams...”
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()”)
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’ve been meaning to write a script that will generate a commit message based on the files changed. “added models.py, edited settings.py”
You can get that information with the git log --name-status parameter.
You can get that information with the git log --name-status parameter.
Awesome, thank you.
I automated a single kind of commit message, which I call "wrench commits" where all I'm doing is running some other tool (package manager, scaffolder, formatter, linter, etc) and committing its changes. These commits I label with a wrench emoji followed by the command line string that was run.
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.
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.
Tell me you have never been responsible for maintaining a code base without saying "I have never been responsible for maintaining a code base"
wass up everyone, I'm the dude that posted that Tweet. Thanks for all the traffic to my profile, and as such to my new startup cr8.art (AI tool for artists).
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.
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.
You could configure your editor to run something like
Then again, if commit messages are pointless, then why bother using version control rather than automatic backups?
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?
We all learn from our mistakes. Some faster, some slower.
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.
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.
I work in a large environment.
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.
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.
So many people are talking about no commit messages, can we talk about the blanket use of "git add ." as well?
>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.
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?
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?
I used to work in a shop where "bad code is okay, we're a startup" and "our entire system depends on spaghetti written by an intern that quit after six months five years ago" were the norm.
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
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
I’d imagine rolenthedeep is trying to communicate that they survived in spite of their confusing codebase, not thanks to it. Maybe they could be shipping even more if they didn’t have to deal with the opportunity cost of maintaining it.
Yeah, pretty much. Last I checked, they've made no major improvements to the game since I left. They've just been pumping out DLC for the last several 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.
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.
Yes, exactly. Throwing tech debt to the wind is going big bags shopping on a credit card. Someone will eventually have to pay the bill.
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.
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're still shipping the same showstopper bugs nearly ten years later.
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.
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.
To this day I see people play the game on YouTube and the player model will glitch out like it always has. Limbs go weird directions, or the tool you're holding will slowly expand to fill the entire screen. Vehicles regularly sink into the ground, or explode, or have a physics glitch that launches them into space.
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.
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.
I would say as an indie hacker, clean code, comments and good commit messages is almost more important than it would be with a small team. One thing I learned building an app over the last year or so is that as a solo dev, you have to be very deliberate and careful with your time. Any time that I spend fixing and refactoring code I already wrote is time that I can't spend building new features to the app. Granted there is a balancing act here but my experience so far has taught me that you want to go the extra mile and make sure your work will not need to be re-written, because that cuts directly into the time you'd spend working on new features.
Small teams can't have any dead weight people or internal limitations.
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.
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.
For me, the biggest benefit of commit messages is for myself, dealing with my own code, to be able to revisit a change that caused a new problem.
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.
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.
don't agree... a commit message can give at least a really high level idea of what's going on before someone bothers to drill down into the commit itself to look.
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.)
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.)
Commit messages might be pointless. Bad commit messages certainly are.
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.
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.
From my experience, commit messages are not actively read by someone, but searched for.
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.
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.
In my view, commit messages are a type of documentation that is often underappreciated. It's the type of documentation you don't miss until those moments when you desperately need it.
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.
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.
> 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
And how do you locate the commit of interest? I usually search the commit messages…
And how do you locate the commit of interest? I usually search the commit messages…
All of the answers to this will amount to being able to find them in some other way.
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.
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.
Git log -Sterm to find commits where term was added or removed.
What if you only remember that the change you're interested in was fixing an issue with the frombulator, not that it did so by changing the "term"? A good commit message in this case would probably mention the frombulator, so you would find it by search and then see that the "term" was changed.
I would try `git log -Sfrombulator`, maybe a comment shows up?
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.
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.
Running a command like git blame on a file you plan to modify and running git show on the sha1 value can help you find relevant commits.
Git bisect is one option, but I usually find myself using "git show HEAD~n" directly.
The title should be the caveat. Anyway, it's funny that this is per-project specific make configuration that you presumably have to set up every time (or resetup if you work on something that doesn't use make) rather than generic personal configuration, such as a bash function. You mean you spend time setting this up on every project?
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!
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's like another form of comments in code. They can be pointless. They can be misleading. Or they can be really informative. They're worth doing for the times that they are informative.
I think I'll disagree with the statement that commit messages are pointless.
> 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).
> 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).
I use this script called "autocommit" and run it in the background in a tab.
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.
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
https://GitHub.com/samsquire/local-development
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
https://GitHub.com/samsquire/local-development
commit messages are not totally pointless, whether you squash merges or not. im fond of squashing on merge and allowing as many and poorly named commits, but when you merge the pr you cleanup the squash commit
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.