8 ms·

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 ch

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.

bloppe 3mo ago
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
- steveklabnik 3mo ago
  Both of these things are discussed in the article. (changelogs and semver)
  - mattrb 3mo ago
    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.
- xigoi 3mo ago
  Auto-generated changelogs from commit messages are bad, no matter if the commit messages follow some structure.
- Mawr 3mo ago
  I suppose it is a significant downside that you could get misled into thinking you can autogenerate a changelog from commit names.
bfeynman 3mo ago
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.
- Guvante 3mo ago
  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.
- Merovius 3mo ago
  > 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".
  - shimman 3mo ago
    [flagged]
SOLAR_FIELDS 3mo ago
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.
- Guvante 3mo ago
  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.
  - rablackburn 3mo ago
    > 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.
    - Guvante 3mo ago
      Tabs are not used consistently for nesting so your argument is missing some nuance. E.g. foo(//long function call\n\t//more parameters)
  - SOLAR_FIELDS 3mo ago
    > 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.
monooso 3mo ago
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/ https://www.conventionalcommits.org/en/v1.0.0/
sharts 3mo ago
But it does enforce a minimum quality
- yencabulator 3mo ago
  Form != quality, as LLMs will happily demonstrate.

bloppe 3mo ago

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

steveklabnik 3mo ago
Both of these things are discussed in the article. (changelogs and semver)
- mattrb 3mo ago
  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.
xigoi 3mo ago
Auto-generated changelogs from commit messages are bad, no matter if the commit messages follow some structure.
Mawr 3mo ago
I suppose it is a significant downside that you could get misled into thinking you can autogenerate a changelog from commit names.

bfeynman 3mo ago

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.

Guvante 3mo ago
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.
Merovius 3mo ago
> 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".
- shimman 3mo ago
  [flagged]

SOLAR_FIELDS 3mo ago

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.

Guvante 3mo ago
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.
- rablackburn 3mo ago
  > 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.
  - Guvante 3mo ago
    Tabs are not used consistently for nesting so your argument is missing some nuance. E.g. foo(//long function call\n\t//more parameters)
- SOLAR_FIELDS 3mo ago
  > 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.

monooso 3mo ago

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/ https://www.conventionalcommits.org/en/v1.0.0/

sharts 3mo ago

But it does enforce a minimum quality

yencabulator 3mo ago
Form != quality, as LLMs will happily demonstrate.