“After 20 years coding I just realised, commit messages are pointless”

https://twitter.com/ashleyrudland/status/1615011065611358211

by wut42 • 4 years ago

27 43 4 years ago

alexb_• 4 years ago

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?

rolenthedeep3• 4 years ago

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

ido• 4 years ago

    If you want your project to last more than a couple of years

And yet by your own reporting the project you're speaking of is still around 10 years later.

tinglymintyfrsh3• 4 years ago

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.

gumby• 4 years ago

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.

_fat_santa• 4 years ago

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.

tinglymintyfrsh3• 4 years ago

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.

100011_100001• 4 years ago

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.

fear91• 4 years ago

Yet another example that years of experience is a poor measure of skill.

jiscariot• 4 years ago

Title of this should really be coder/influencer/marketer/guru TILs the alias command exists.

renewedrebecca• 4 years ago

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.)

travisjungroth2• 4 years ago

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()”)

WorldMaker2• 4 years ago

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.

u801e3• 4 years ago

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.

travisjungroth2• 4 years ago

Awesome, thank you.

dgant• 4 years ago

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.

w4rh4wk5• 4 years ago

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.

WorldMaker2• 4 years ago

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.

scintill762• 4 years ago

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…

JoeyBananas• 4 years ago

Git bisect is one option, but I usually find myself using "git show HEAD~n" directly.

mejutoco2• 4 years ago

Git log -Sterm to find commits where term was added or removed.

scintill762• 4 years ago

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.

thinking4real• 4 years ago

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.

u801e3• 4 years ago

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.

seeknotfind• 4 years ago

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!

AnimalMuppet• 4 years ago

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.

KronisLV• 4 years ago

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).

samsquire• 4 years ago

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.

  #!/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 actually use it from host machine to push to a development virtual machine without vagrant.

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

penjelly• 4 years ago

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

nunez2• 4 years ago

Commits are indeed pointless...if you do merge/pull requests (or the equivalent on whatever collaboration platform you use).

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.

erik_seaberg• 4 years ago

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.

nunez2• 4 years ago

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!

tinglymintyfrsh3• 4 years ago

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.

u801e3• 4 years ago

You could configure your editor to run something like

    git commit --allow-empty --allow-empty-message -a

everytime you save or the editor auto saves.

Then again, if commit messages are pointless, then why bother using version control rather than automatic backups?

bob1029• 4 years ago

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.

scelerat• 4 years ago

Tell me you have never been responsible for maintaining a code base without saying "I have never been responsible for maintaining a code base"

thesnide• 4 years ago

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.

ashleyrudland87• 4 years ago

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.

lsaferite• 4 years ago

So many people are talking about no commit messages, can we talk about the blanket use of "git add ." as well?

“After 20 years coding I just realised, commit messages are pointless”

Related Stories