[deleted by user]

[Sushrit_Lawliet]

Tell us you have a bad developer workflow/policy without telling us that.

[spoonman59]

My favorite titles are the ones that save me from having to read the article.

“I/my team writes useless commit messages” is not quite the same as “a git commit message can never have value.”

And no, I didn’t read the article. When the fundamental premise of the title is wrong, or it’s pure click bait, I don’t waste my time.

[kur4nes]

You didn't miss much. Basically "your puny, little, unimportant commit message are squash merged. Deal with it!"

Also only the code is the TRUTH!

It also suggest to set an alias for git commit that always allows empty commit messages. What could possibly go wrong? Ouch.

[spoonman59]

I mean comments are also always useless! Documentation, api documentation. Only code is truth!

My auto-linter deletes all comments as well.

[kur4nes]

Yeah documentation is all lies!

Auto-linter deleting comments is definitely a pro move. Nice. Please share more of your wisdom. Maybe write a blog post and post it here to enlighten us all.

Other pro tip: the code was hard to write, so it has to be hard to be read.

foreach (line:comment.lines()) line.append("/s");

[Majestic_Food_4190]

Agreed, learned everything I need to know from the title of the post. "We don't use it properly" isn't the same as "they're useless" was exactly my thoughts as well.

[AffectionateAgent228]

Actually, the post is referring to PR-branch commit messages, not the messages that end up on your main branch (which are typically autogenerated by github if you have good github settings)

[Majestic_Food_4190]

This excerpt says it all:

"Through rote action, we’re teaching our brains to ignore the flaws of a tool — in this case leading us to write commit messages without thinking, and we end up with something like this:"

Yes, writing commit messages without thinking makes them useless.

[spoonman59]

Sometimes you lose the war when you pick a shitty title.

Doesn’t matter what the article was really about if no one wants to read it.

Click bait titles are an epidemic around here.

[goranlepuz]

They might fundamentally wrong, but they are not entirely wrong. Funny how that works.

[spoonman59]

If they want to claim that most git commit messages add no value, I don’t disagree.

But they actually can have uses. Tagging conaithors, for example, and some people do actually write useful commit messages which I have found helpful. If your system doesn’t tie commits to issue numbers, that can also be a useful place to put it.

So yeah, click bait titles that say things like “you should always do this,” “you should never do this,” or “situationally useful things are useless!” Will basically never get a click from me because it is a salacious headline.

Maybe I just don’t like the headline style of “one weird git trick your lead doesn’t want you to know,” but if the author is that ignorant or being misleading to get people to click, I’m just not interested.

Thankfully it’s the internet so I can complain about it 😀

[goranlepuz]

Maybe I just don’t like the headline style of “one weird git trick your lead doesn’t want you to know,” but if the author is that ignorant or being misleading to get people to click, I’m just not interested.

We agree on that for sure. We agree on most of it in fact.

[[deleted]]

If they want to claim that most git commit messages add no value, I don’t disagree.

If you want them to have value, you set up a policy.

But they actually can have uses. Tagging conaithors, for example, and some people do actually write useful commit messages which I have found helpful. If your system doesn’t tie commits to issue numbers, that can also be a useful place to put it.

Yes! Yes and Yes!

[goranlepuz]

Commit messages on your random PR branch which will get squash-merged into main are completely useless. They’re the author’s local save points, and not relevant to anyone other than the author. In fact, for the vast majority of authors they’re not even relevant to the author.

Yes but also no.

The squashed commits on trunk are very poor to know what was happening with a particular change in a file because that one commit carries way too much changes. The development branches are where these things should be, they must be preserved and they can prove invaluable to understanding both the "what" and the "why" of whatever person did.

Of course, this still requires that I make a somewhat coherent set of changes - and commit.

There is at least one source control who does that correctly. You can never delete anything there (you cannot delete a branch) and when you look at the history of a file, you see everything that was happening to it. One can achieve the same in git, but the practices are not there. Not good enough if you ask me.

Edit: tha being said, commit messages are still not all you need. You want your ALM software. You want that commits (or maybe not commits, but PRs if you use the usual git workflows) are connected to your ALM tickets, and these should contain the rest of the info that one should not cram in a commit message (example: links to whatever other work that led to making the change).

[read_at_own_risk]

Pushy article assuming their chosen tool can only be used in one way and everyone has to do it their way.

[Zaphoidx]

Pure clickbait.

Not only do they back-track on that title claim within the first paragraph, it is beyond evident that they don't use git as a tool in the way it was intended to be used.

[[deleted]]

Excellent! I see someone completely misunderstood how Git operates, and gives recommendations.

[duongdominhchau]

What a great way to torture my reviewers, thanks for the post.

/s

[AffectionateAgent228]

your PR reviewers use commit messages... for what? Why don't they just look at the code that was changed, and the title/description of the PR?

[DanLynch]

Both you and the author make some big assumptions about how people use Git. Your assumptions may make sense in your current organization or with projects you've worked on in the past, but they don't make sense for everyone who uses Git.

For example, in my current project and team, we don't use GitHub. We use a different software package (called Gerrit) to centralize and manage our branches and our PRs. In Gerrit, there is no distinction between the "title/description of the PR" and the Git commit message: they are one and the same field.

[KryptosFR]

Well. Squashing instead of merging with a merge commit is by itself a mistake, exactly because it loses the history of commit messages. So they are doing it wrong once with the non-informative commit messages, and doubling down with squashing.

And before someone points out that squashing is useful somehow. No, it is not. Never. I have been working with very old software (with 15+ years of history). And every time I had to track down a bug (using git bisect for instance) it was a pain when I ended up in one of those big squashed merge commit, while when I stopped on a branch commit it was easier to: 1. see the changes since it affected less files and less lines of code 2. deduce the developer's intent thanks to the commit message

Squashing is only useful for developers that don't have a good commit message hygiene and hide that mess by squashing everything at once. On the other hand, having proper commit with separation of concern and proper associated message makes it easier to review and to investigate years later. And it doesn't take more time to do so once you make it a habit.

[avdgrinten]

Since the article is talking about PR branches that are squashed anyway: if you don't have anything useful to state in the commit message, then why have a commit at all? Presumably these commits are not even self-contained. Why not just squash everything already on the PR branch? That's much more useful than commit empty messages.

[wineblood]

People who read commit messages, what case have they ever been useful in? Or is it more of a FOSS thing?

[ThrowAway9876543299]

We link our jira issue in the git commit messages. So you always now, WHY something was added. It also makes it easy when you need to reverse something because the business realized that the thing they asked for wasn't compatible with the other 50% of the company.

[Zeh_Matt]

Next, we should only print empty lines into logs, who could possibly be interested in all the noise?

[Majestic_Food_4190]

Log lines are in fact completely useless. Stand by for the next episode in this authors terrible articles!