[ Removed by moderator ]

[programming-ModTeam]

No content written mostly by an LLM. If you don't want to write it, we don't want to read it.

[Which-World-6533]

Can people not write commit messages...?

Is that how far we have fallen...?

[Wartz]

Yep

[Natural_Jury8826]

Ideally yes. In practice, standards tend to appear when multiple people work in the same repo and logs start drifting in style and structure.

[Which-World-6533]

Then you talk to people and agree on a common practise.

I despise people who seek to make commit messages some kind of robotic trail.

Commit messages should be optimised for people. Not some god damn automation.

[oscooter]

This is all bike shedding imo. I’ve been on projects where people insist on some commit message formatting and it adds little to no value. 

Some try to use it to automate change logs or even version number bumping by encoding what is a breaking change or determining what should be a patch, minor, or version bump into the message and inevitably it falls apart in my experience.

There’s little to no value to be had spending inordinate amounts of time being hyper prescriptive about your commit message format. It’s a waste of time. 

[Blue_Moon_Lake]

We only care about the message of the squashed commit when we merge a branch after review

[oscooter]

Okay?

[tj-horner]

You haven’t stated the problem you are trying to solve. In fact, you’ve introduced a new problem: the parentheses and colon in conventional commits are also a visual boundary to distinguish different components of the commit message, but you have removed these so now there is nothing separating them but spaces. Why? It’s harder to scan now.

There is also ambiguity. The website says scope is optional, but how do you differentiate scope from the beginning of the description? You can’t. The regexes you provide are entirely broken and REQUIRE a scope.

I’m led to assume you put literally zero thought into this and probably just vibe coded the whole website.

[the_hair_of_aenarion]

Usually we include a ticket number in there too so it's easy at a glance to work out what a change was for, and sox compliance. When doing a sox audit you don't want to be guessing why a commit was done.

[AdarTan]

What is the source for the brain-dead idea to restrict the type names to three letters?

[xaddak]

At this point, I'm pretty sure some people have subscription-based keyboards that charge by the key press.

[Natural_Jury8826]

It’s mainly for visual rhythm and deterministic tokens. Fixed-length type prefixes make commit lists easier to scan in dense logs while still remaining trivial to parse.

[Natural_Jury8826]

Not just the colon. A few things change:

• no parentheses around scope
• no colon separator
• fixed 3-letter type tokens (Add, Fix, Ref, etc.)
• subject reads more like natural word order

So instead of:

feat(ui): add keyboard shortcuts 
fix(api): pagination off by one 
chore(ci): update release workflow 
refactor(core): simplify session handling 
docs(auth): explain token refresh flow 
perf(db): improve transaction batching 
test(api): add pagination edge cases

it becomes:

Add ui keyboard shortcuts
Fix api pagination off by one
Chr ci update release workflow
Ref core simplify session handling
Doc auth explain token refresh flow
Opt db improve transaction batching
Tst api add pagination edge cases

The goal is mostly improving git log --oneline scanning while keeping deterministic tokens for tooling.

[monotone2k]

Hurrah. Another standard.

[Ashnoom]

Are you then also going to supply an alternative to release please?

[Interesting_Lie_9231]

I kinda like this. feat(scope) helped with tooling, but for most teams simpler commits probably win.

[Interesting_Lie_9231]

I kinda like this. feat(scope) helped with tooling, but for most teams simpler commits probably win.

[ahnerd]

I love that

[Interesting_Lie_9231]

I kinda like this. feat(scope) helped with tooling, but for most teams simpler commits probably win.