Conventional Commits encourages focus on the wrong things • Hacker News Board

Re: Conventional Commits encourages focus on the wrong things

#221

Post by Guvante » Sat, Jun 06, 2026, 1:46 AM UTC

bfeynman wrote: post #194

olzhasar wrote: post #120

Earlier quoted context omitted.

Defined structure does not constitute quality. A commit message can be loosely structured, but be very insightful and good at communicating the nature of the change. On the flip side, one can make a very structured but confusing or non-informative commit message. I generally tend to agree with the author, conventional commits do not solve the core issue of the poor commit messages problem.

why is "solving" the issue somehow the bar? software engineering has more practices rooted in psychology than engineering, its a moving and ambiguous target. Using conventional commits gives you a framework and mechanism that undoubtedly improves contribution semantics.

Why undoubtedly?

In what context does wasting your first characters on fix vs feat matter?

PRs are going to have an explanation that has way more detail than necessary to figure that out quickly.

One lines tend to be (for me) in a situation where the difference is immaterial. If I am rapid firing through history I need to know what you did not why you did it.

Again I am not claiming that these are bad or even that they aren't good.

I am specifically disagreeing that any change is automatically good, that isn't true.

Re: Conventional Commits encourages focus on the wrong things

#222

Post by Guvante » Sat, Jun 06, 2026, 1:48 AM UTC

SOLAR_FIELDS wrote: post #216

olzhasar wrote: post #120

Earlier quoted context omitted.

Defined structure does not constitute quality. A commit message can be loosely structured, but be very insightful and good at communicating the nature of the change. On the flip side, one can make a very structured but confusing or non-informative commit message. I generally tend to agree with the author, conventional commits do not solve the core issue of the poor commit messages problem.

It’s the linting argument all over again. I don’t give a shit what the style is. I give a shit that it’s consistent. Form whatever opinion you want about how you want to format your code, structure commit messages etc. I don’t really care, if you want to start every commit with “poop(fix): pooper my commit message”, as long as you’re consistent about it and enforce it programmatically you have my emphatic support Thi…

That is only true of semantically equivalent things.

Tabs vs spaces don't matter they are equivalent.

But consistency is only better when it is an improvement.

It is fundamentally important that convential commit is better for adopting it to be an improvement.

After all in your example wasting the first four characters of your commits with poop would objectively reduce the quality of your commit history, whether or not it was consistent.

Re: Conventional Commits encourages focus on the wrong things

#223

Post by c-hendricks » Sat, Jun 06, 2026, 1:55 AM UTC

mh-cx wrote: post #13

My main complaint with conventional commits always was that they don't include an issue number in the commit title. It's not even mentioned in their standards as optional or something. To me this is almost the most important information in a commit message. I don't know how often in the last 15 years I was cross checking the issue description referenced by some old commit to get the full context of a change. I also f…

It's only a convention around commits suggesting to prefix them with certain short words, there's nothing stopping anyone from including issue numbers.

All ours at work do: "feat[component]: DEV-1234: description"

Re: Conventional Commits encourages focus on the wrong things

#224

Post by masfuerte » Sat, Jun 06, 2026, 1:57 AM UTC

yifanl wrote: post #176

hn_throwaway_99 wrote: post #109

As programmers I feel like we'll always nitpick and bitch over what the optimal setup is for rather mundane things (tabs v spaces, yada yada). I'm not saying that conventional commits are God's given best way to structure a commit message, but they are a defined structure , and I find it much more effective and important that some expectations be set around commit messages, and I think conventional commits are as goo…

Some programmers prefer 2 spaces, some programmers prefer 4, why don't we compromise and pick a number between 2 and 4?

π?

Re: Conventional Commits encourages focus on the wrong things

#225

Post by c-hendricks » Sat, Jun 06, 2026, 1:57 AM UTC

jeremyjh wrote: post #219

osigurdson wrote: post #75

I'd much rather people think deeply about summarizing their work. This helps others understand it but, more importantly, helps the developer understand what they did. If its hard to summarize, maybe it should be tightened up a little for instance. Enforcing a "schema" might help a tiny bit but also can cause people to check out a little as it can feel like just another meaningless process.

Exactly. People latch onto these perfunctory standards because it’s easier than understanding and clearly communicating the work they’ve done.

Or they could be used as a stepping stone in teaching people the value of being able to summarize what they've done?

Re: Conventional Commits encourages focus on the wrong things

#226

Post by jeremyjh » Sat, Jun 06, 2026, 2:33 AM UTC

c-hendricks wrote: post #225

jeremyjh wrote: post #219

Earlier quoted context omitted.

Exactly. People latch onto these perfunctory standards because it’s easier than understanding and clearly communicating the work they’ve done.

Or they could be used as a stepping stone in teaching people the value of being able to summarize what they've done?

How does typing “fix:” or “feat:” get you a step closer to being thoughtful?

Re: Conventional Commits encourages focus on the wrong things

#227

Post by awill88 » Sat, Jun 06, 2026, 2:39 AM UTC

You know what lacks focus? This whole article. Oh, and also individual styles of commit messages. You know what’s a waste of everyone’s time when you’re building technology in 2026? How to write and summarize what you’re work is doing.

Conventional commits doesn’t make a promise, it’s a specification. Words have power and meaning, this viewpoint is about more than a spec, it’s about the popularity and relevance that they clearly despise.

Conventional commits are like BEM syntax for CSS, it works if you pay attention. It’s structure around what developers do, which thoughtful limits. What is the problem with that? Is it the only way? No. But to say it’s encouraging the “wrong things” pshhhh

This author’s take is dog water for coders who yearn to be controversial and (clearly) focus on the wrong things.

Re: Conventional Commits encourages focus on the wrong things

#228

Post by andrybak » Sat, Jun 06, 2026, 2:46 AM UTC

IshKebab wrote: post #167

hebleb wrote: post #47

Earlier quoted context omitted.

If i'm looking at git history, the ticket number is the most useful piece of info to get more context on the changes for me

Ok... but why does it need to be in the title?

if IDE supports converting them into clickable links, then scrolling through a log in its Git integration (kinda like `git log --oneline`) will be a convenient list of links to issues. If the commit messages are good, you just skip over the Jira issue/ticket key/ID. If what you want is to see the requirements of a feature or steps to reproduce of a bug or some other context for the ticket, then a clickable link is very convenient. Of course, sometimes it does make sense to include some of that information in the commit message as well.

When working in big teams, it can be very hard to increase the usefulness of commit messages. On the other hand, enforcing inclusion of a Jira issue key in commit messages is easy to implement. Relying on issue tracker descriptions can be a difficult proposition as well. Quality of individual ticket descriptions can be low; depending on how responsibility for maintenance is handled, the bug tracker migrations can sometimes be handled improperly and information can be more easily lost than in a Git log.

Re: Conventional Commits encourages focus on the wrong things

#229

Post by boltzmann64 » Sat, Jun 06, 2026, 3:06 AM UTC

Wait. i am already struggling with 50 columns for the title, now i have add this `[scope]:` bloat to it? How are these people doing both "Conventional Commits" and 50-72 at the same time?

Re: Conventional Commits encourages focus on the wrong things

#230

Post by xigoi » Sat, Jun 06, 2026, 3:23 AM UTC

bloppe wrote: post #139

olzhasar wrote: post #120

Earlier quoted context omitted.

Defined structure does not constitute quality. A commit message can be loosely structured, but be very insightful and good at communicating the nature of the change. On the flip side, one can make a very structured but confusing or non-informative commit message. I generally tend to agree with the author, conventional commits do not solve the core issue of the poor commit messages problem.

Conventional commits made it easier to generate changelogs and automate semantic version bumps. I suppose LLMs can usually do that the right way with looser structure, but in the before times it made a lot more sense, and even now is much less ambiguous

Auto-generated changelogs from commit messages are bad, no matter if the commit messages follow some structure.