What I don't understand is why you would object to having more metadata attached to your commits. That is essentially what CCs are: additional metadata. Just like the author, date, Co-authored-by, Signed-off-by, and other trailers. It is information that can help you use your Git history in different ways.
You may find no use for this information, or find that it clutters the subject line, but I've addressed both arguments in my previous replies, and won't repeat it here.
> If I'm looking for a bug fix [...]
I mentioned a bug fix as an example, so I'm not sure why you're so focused on that.
CCs introduce a convention to how type and scope are specified. You're not required to use any of the proposed types, and should certainly come up with scopes that make sense for your code base. How you use that information is up to you, and I mentioned several ways that I've personally found it useful.
> The discipline of organizing commits is orthogonal to the discipline of labeling them.
I don't follow. You organize things by grouping them according to some criteria, and labels are required to uniquely identify those groups.
> One that is thoughtfully written by hand will naturally include the scope of the change any time that this concept is meaningful.
Ehm, sure, but CCs provide a framework that standardizes the way information is presented in a well structured repository. A scope is something most repos already use; i.e. it's common to see `<scope>: ...` in repos that don't follow CCs. Attaching a type of commit is another bit of information that further groups commits, and the notation `<type>(<scope>): ...` is just the suggested convention. Which, BTW, naturally came from the way some projects were already structuring their commits.
> I mentioned a bug fix as an example, so I'm not sure why you're so focused on that.
Did you consider it was an example in their comment as well? Fewer features than bug fixes are single commits for example.
> You're not required to use any of the proposed types
> the notation `<type>(<scope>): ...` is just the suggested convention
Commits MUST be prefixed with a type, which consists of a noun, feat, fix, etc., followed by the OPTIONAL scope, OPTIONAL !, and REQUIRED terminal colon and space.
The type feat MUST be used when a commit adds a new feature to your application or library.
The type fix MUST be used when a commit represents a bug fix for your application.
A scope MAY be provided after a type. A scope MUST consist of a noun describing a section of the codebase surrounded by parenthesis, e.g., fix(parser):[1]
[1] https://www.conventionalcommits.org/en/v1.0.0/
Ha. That's just the language of the RFC specification. This is not some protocol you MUST support exactly as described. It's an attempt at standardizing a convention, and such language makes it easier to follow.
Regardless, blindly following any proposed software development convention or practice is rarely a good idea. It's smarter to get informed, pick and choose practices that make sense to you, and adapt them to your specific workflow.
If you don't find what the Conventional Commits specification proposes valuable, that's fine, but my argument is that it's shortsighted and a mistake. Cheers!
> why you would object to having more metadata attached to your commits
It gets in the way because it takes pride position at the start of the commit message. If you want to put it at the end that might be less annoying but I've never seen anyone do that.
I think the main point is that I almost never arrive at a commit by exhaustively reading through a list of commit messages. It's almost always through some other kind of link like git blame or a GitHub issue/PR.
It's also just really low value information. Imagine if every commit message started with how many lines of code it changed. That would be pretty annoying right?
It's pretty handy when tools like lazy.nvim display changes as a list of commit summaries and you have to make a fast value judgment on if you should allow the upgrade.
Outside of that, I agree that it's silly to put it in the summary and seems to be a symptom of people writing crap commit messages.
If all you ever write or look at is the summary then obviously it needs to go in there or it'll never be seen.