I agree, I hate conventional commits. Why the hell do I care if changes are chores or features? I want to know what the change was.

▲

imiric 10 hours ago | parent [-]

I'm surprised to read that someone not only finds no value in conventional commits, but actively hates it. Wow.

A few reasons to care about CCs:

- The first few characters of a commit message tell you immediately the type of change you should expect. This tells you part of the "what" at a glance. If you're looking for a bug fix, for example, you can safely ignore any other type of commit.

- 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.

- A conventional commit message also often includes the change scope. This is a handy way to indicate the subsystem that was changed, which is also useful for filtering, searching, aggregating, etc.

- They help with writing change logs. I'm a strong proponent of the idea that change logs shouldn't be just autogenerated dumps of commit messages, but carefully redacted for the intended audience, and CCs can help with grouping changes by type or scope. These days LLMs do a decent job at generating this type of changelog (even though it should still be manually reviewed and tweaked), and the additional metadata provided by CCs helps them make it more accurate.

▲

zahlman 9 hours ago | parent [-]

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.

▲

imiric an hour ago | parent [-]

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.

	▲	IshKebab 39 minutes ago \| parent [-]
		> 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?