[YorickPeterse]

I agree that full sentences (e.g. like Email subjects or blog post titles) are better. Tagging commits with feature/bug/etc is not particularly useful, as more often than not the line between feature, bug, etc is blurry. At times it can also be unclear what tag to use, leading to arbitrary choices. For example: is a performance improvement a feature, or a bug fix? The tags also add no value when reading commit messages.

Setting that aside, the conventional commit "standard" (https://xkcd.com/927/) doesn't focus on what I think is the most important aspect of a commit: a good commit subject and message. In fact, prefixing the subject line with certain tags limits the amount of characters you have for writing the message; assuming you want to stick with the usual 50 character limit.

[JMTQp8lwXL]

> feature/bug/etc is not particularly useful

It's useful for automatically determining the next semantic release version by inspecting the commit history alone.

fix: <-- patch

feat: <-- minor

breaking: <-- major

[bluejekyll]

So why not just use patch, minor, major? Then we don’t even need the indirection.

Some fixes will require breaking changes. Fixes can be part of the message with the issue #, etc.

[boudin]

In this case you suppose to add a ! after fix: fix! By using patch, minor and major you lose some information (the purpose of the commit)

[munk-a]

That seems inaccurate, it looks more like fix: feat: are both potentially patch level while fix!: feat!: breaking change: and breaking change!: indicate major changes... possibly? Ouf I think the commit is just absolutely the wrong level to encode this at - I much prefer ticket level encoding of this information.

[JMTQp8lwXL]

I was explaining how standard-version [0] works. Conventional Commits homepage doesn't mention anything about the '!' syntax. [1] I'm unsure if you're suggesting that's how you think it should work, or how it actually works. I haven't ever tried using the '!' syntax, so I can't say for certain.

In terms of release management, it makes configuring CI jobs simpler with one less parameter. If you automatically release merges to master, you can use standard-version with conventional commit syntax. On other projects, I've seen people use GitHub PR labels to mark 'major', 'minor', or 'patch' releases (the CI system reads this information when generating releases).

If you feel it's inappropriate for this information to live in your commit history, you'll need to specify it through one of these other options.

Since I don't have a dedicated team for this sort of infrastructure (I maintain my own Jenkins jobs), I find that Conventional Commits get the job done, so I can focus on other things. There could be better ways, but I have more pressing problems than demand my attention, with higher priority than optimizing my CICD configurations.

[0]: https://github.com/conventional-changelog/standard-version

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

[arethuza]

[1] has:

"or appends a ! after the type/scope, introduces a breaking API change"

[Vinnl]

I've got an "Unreleased" section in my changelog in which I log any changes that are relevant to consumers, with sections for bug fixes, new features, and breaking changes. No need to clutter my commits with that.

[eyegor]

> the usual 50 character limit.

People do this? I guess it's fine if your commits are <100 lines of code but it seems needlessly concise, to the point of losing information.

Personally, almost all my commits follow email styling: first line tries to be concise, newline, then a list of what changes have been made along with a brief justification. Feels like a bare minimum unless you'd rather tie everything into pr's (which can't be seen from command line). This is why for people unfamiliar with git I refuse to tell them about commit -m because I feel it leads to undocumented history when you need to audit code.

disclaimer: I tend to work on long lived projects (5+ years)

Edit: bonus point that I forgot - by having a detailed commit log that reads like prose, it's easy to explain "everything you guys are working on" to the non technical folks.

[TheDong]

You're arguing against a strawman because you misunderstood the parent comment.

The character limit was only referring to the subject line. Under it you can have as many lines of additional context as you wish. That's the normal way; the subject is brief, the message is arbitrarily long.

For what it's worth, the linux kernel limits it to around 70 chars and uses a subsystem prefix, so clearly that can work on large long-lived complex projects.

Your argument against 50 characters in the entire message, including the body, is not one anyone would ever argue for, so you've constructed a complete strawman.

[Vinnl]

And some useful context: the 50-character limit is the result of the subject lines then being readable next to a commit graph that Git can display.

[dmurray]

Surely the most important part of a commit is the code committed, not the accompanying message.

[iainmerrick]

Yes and no. Both are important.

The code is what actually gets run, sure, but good code with bad or misleading documentation can cause trouble later on. Commit messages are documentation.

[cyphar]

And commit messages are possibly the best form of documentation when it comes to debugging a problem -- it lets you know exactly what a developer was thinking when the code was written.