Conventional Commits encourages focus on the wrong things
sumnerevans.com
Conventional Commits encourages focus on the wrong things
1–10 of 294 posts
Re: Conventional Commits encourages focus on the wrong things
#2As a solo developer, I rarely struggle to remember what changed yesterday. I often struggle to remember why I made a decision six months ago.
Conventional commits are most valuable to me as historical context rather than as a release-management tool.
The larger the project becomes, the more useful that context gets.
Re: Conventional Commits encourages focus on the wrong things
#3Asides from the well made points here ('scope is more important than type' etc).
> something like fix, feat, chore, docs, or refactor
'Docs' are also part of the program, they need fixes too, and features need docs. If the docs don't match the features because they're not being updated when the code is, the docs are a lie and waste other developers time.
Also if you were writing a standard: why would you randomly abbreviate 'feature' but not 'refactor'? That sounds like a nitpick but standards require great thought, this is a bit of a smell that there hasn't been much thought into designing 'conventional commits'.
Finally: the name 'Conventional commits' is a land grab (reminds me of when someone made a JS Standard and called it 'StandardJS', ignoring every existing popular standard). From the article, the *actual* convention is 'scope: work"
- Linux
subsystem: description
prefix: description
area: description
package: description
pkg-name: descriptionRe: Conventional Commits encourages focus on the wrong things
#4“The audience of a changelog is entirely different than the audience for a commit log!
A changelog is user-facing”
I'd say that ship has probably sailed. Most companies are happy with “Bug Fixes & Performance Improvements”. At least if they're not going to put the effort in, then a generated changelog is better than nothing.
Re: Conventional Commits encourages focus on the wrong things
#5I don't care much what it says as in "fix", "chore" etc, but for me the main benefit is breaking changes indicated with "!", something like "feat!: ...
".
This makes neovim plugin manager highlight the change differently which brings attention to it when you update stuff.
So please do use it instead of complaining!
I do like the suggestion of
scope!: ...
if it will be treated the same way with breaking changes reactions.
Re: Conventional Commits encourages focus on the wrong things
#6[dead]
Re: Conventional Commits encourages focus on the wrong things
#7[flagged]
Re: Conventional Commits encourages focus on the wrong things
#8As a solo developer, I rarely struggle to remember what changed yesterday. I often struggle to remember why I made a decision six months ago. Conventional commits are most valuable to me as historical context rather than as a release-management tool. The larger the project becomes, the more useful that context gets.
This sounds like what regular commit messages do. How are conventional commits specifically helpful?
Re: Conventional Commits encourages focus on the wrong things
#9As a solo developer, I rarely struggle to remember what changed yesterday. I often struggle to remember why I made a decision six months ago. Conventional commits are most valuable to me as historical context rather than as a release-management tool. The larger the project becomes, the more useful that context gets.
That information should still be in the commit messages. "No functional change intended." appears widely in FreeBSD commit logs when code is being refactored (or, rarely, restyled).
And the issue isn't whether you can remember what you changed yesterday; this is largely about making sure other developers can quickly identify relevant commits. If you're a solo non-OSS developer, this is entirely relevant to you.
Re: Conventional Commits encourages focus on the wrong things
#10The author's example of a conventional commit is not correct anyway IMO, which is maybe why they think the "fix" part is redundant:
> fix: prevent foo from bar'ing
The whole idea of conventional commit is:
> fix: [problem]
so the correct conventional commit would be:
> fix: foo bar'ing
which is succinct and perfectly fine.