I'm with Ish on this one.

> The first few characters of a commit message tell you immediately the type of change you should expect.

1. Why do I care about this particular classification of "type" of change?

2. "The first few characters" of the message aren't actually what I necessarily see first, anyway.

> If you're looking for a bug fix, for example, you can safely ignore any other type of commit.

1. If I'm looking for a bug fix, I'm using tools like git blame and git bisect.

2. How often do bugs actually get fixed by a single commit, that has that bug fix as their sole purpose, and which is recognized as a bug fix at the time of writing? I'm guessing it's much lower than one would naively expect.

3. If I'm looking for a bug fix, I'm looking for the fix for a specific bug, which is probably most recognizable by some bug tracker issue ID. (And if not, it's most searchable that by figuring out an ID and looking that up). So I'm scanning lines for a # symbol and a number, which I would definitely not expect to be at the start of the line.

> Thinking about the type of change you're committing helps you create atomic commits. Anything that is not strictly related should go in a separate commit. Hopefully you already know why you should care about this.

Yes. And I do this by thinking about a verb that naturally belongs at the beginning of the sentence (fragment) describing the commit. "Bugfix", "feature", and "enhancement" aren't actions.

The discipline of organizing commits is orthogonal to the discipline of labeling them.

> A conventional commit message also often includes the change scope.

One that is thoughtfully written by hand will naturally include the scope of the change any time that this concept is meaningful.

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.