Conventional Commits encourages focus on the wrong things

So much commit hygiene and fuss appears git induced. Use something other than git and the problems disappear.

Commit messages are good release notes rarely.

> I enforce CC on my projects because I don’t have the energy to police horrendous commit messages.

And does it actually accomplish that goal? I've been on several projects where someone pushed CC on the team with this reasoning. Every time my experience has been that you get the same crappy messages with a tag that may or may not be accurate.

BTW, AI absolutely knows how to bypass pre-commit hooks and will do so when they come up with some reasoning why their situation is an exception to the rule. I've watched them do it. The only way I've found to strictly enforce things on an agent (tests, linting, whatever) is to use a claude pre-command hook that will block git commit if the checks don't pass.

I like relying on `git tags` even in continuous delivery situations. `git describe` is often good enough for continuous delivery versioning `v1.2.3-4-gabcdef` can describe a commit exactly enough to make git happy and is semver-like enough to set expectations, even/especially if new `git tags` are only ever inserted on human discretion (this is breaking change so I need to tag a new major now). The only real debate with `git describe` format version numbering is if to better conform to semver expectations the first dash should be a plus or not and you can do that change with a quick regex if you feel it is worth it for whatever is enforcing your semver expectations (ordering versions correctly in a package manager, for instance).

`git describe` is easy to automate for CD, but can leave version number decisions to people via `git tag` choices (and/or GitHub Releases) rather than trying to guess from commit history magic keywords.

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 good as anything.

Like the author is making a big deal that they think scope is more important than type. I may tend to agree, but I think the difference between "fix(compiler)" and "compiler fix" is not exactly a hill I'd be willing to die on.

The tech industry has tons of things that became standards even if they weren't optimal. E.g. if one were starting from scratch I think any sane person would argue JSON should support comments (sorry but Douglas Crawford's rationale for not including comments never made sense to me), better defined numeric formats, etc. But it was better in many contexts than what came before it, so it became the standard. I could believe that there is some other format that differs a bit from conventional commits that is a little better, but not really better enough to want a whole other competing way of structuring comments.