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

Both of these things are discussed in the article. (changelogs and semver)

They're hand-waved away by saying the changelogs are bad and the semver isn't always accurate. While I mostly agree with, that doesn't mean they don't provide _some_ value. You get categorized changelogs (even if the messages are technical) and semver that's generally correct. The alternative of good changelogs and perfect semver isn't free.

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

I suppose it is a significant downside that you could get misled into thinking you can autogenerate a changelog from commit names.

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.

> Using conventional commits gives you a framework and mechanism that undoubtedly improves contribution semantics.

I do not want to contribute to a project using conventional commits. I have consistently found, that I am unable to decide what the "type" of a commit even is and I feel unnaturally caged in into how I would split up commits, by having them be restricted to types (it doesn't help that the conventional commits I've seen appear to decide the type by fair dice roll).

Discouraging contributions does not "undoubtedly improve contribution semantics".

Sounds like a you problem because I never had a issue taking 30 seconds to read a contributors guide.

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

This comment assumes you are picking between a conventional commit message or something better. But the reality is you are almost always picking between a conventional commit and Nothing.

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.

> Tabs vs spaces don't matter they are equivalent.

Just to nitpick (because what else is this thread about? :))

They aren't equivalent! Tabs carry more semantic information than spaces. 1 Tab character == 1 Level of nesting

Space-based systems _can_ provide the equivalent semantic information if they are 100% consistent.

...but part of the argument in favor of spaces is that they allow an escape hatch of the strict indentation in order to allow pleasing visual alignments.

Tabs are not used consistently for nesting so your argument is missing some nuance.

E.g. foo(//long function call\n\t//more parameters)

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

Absolutely! Which means we can also agree that conventional commit is objectively better than No System For Their Commits At All, which is what 99.9% of people are actually choosing between when evaluating conventional commit. They aren’t looking at conventional commit vs Some Better Way, they are looking at “we have no standardization of commit messages” vs “we have standardization of commit messages”.

For the 0.1% people for whom that’s not good enough, one hundred percent agree that these people should be pursuing better solutions.

Did you just not read the rest?

I was quite clear you are presupposing it is better without actually justifying that.

"Some standard is better than no standard" isn't generally true, it has some requirements.

I don't think it's reasonable to judge Conventional Commits on something it doesn't claim to do.

I can't see any suggestion on the CC site [^1] that it "solve[s] the core issue of the poor commit messages problem."

Rather, it's explicitly described as "a specification for adding human and machine readable meaning to commit messages."

I'd say it accomplishes that modest goal.

[^1]: https://www.conventionalcommits.org/en/v1.0.0/

But it does enforce a minimum quality

Form != quality, as LLMs will happily demonstrate.