> strictly enforces the Conventional Commits specification (feat, fix, chore, etc.).

Nope. Waste of bytes in my commit message header that are better done by git trailers.

Otherwise, I love the idea of the tool. I personally try to answer “why does this commit exist?” when I create commits.

withinboredom 12 hours ago | parent | next [-]

I have a coworker that makes every branch into a story about wizards, elfs, or whatever. There's a whole arc that explains the story of the commit in a fun way. I have no idea how he comes up with it all for the past 10 years.

	▲	g-b-r 6 hours ago \| parent [-]
		rotfl can you upload some of that somewhere?

▲

crabmusket 8 hours ago | parent | prev | next [-]

I find that the CC structure helps me scan a list of recent commits, e.g. when squashing something into a past commit or trying to find where to navigate.

I don't spend a lot of time on trying to come up with scopes etc, I just make sure that my commit does one thing that fits the label.

▲

layer8 9 hours ago | parent | prev | next [-]

These categories can be useful, as they indicate part of the “why”. I just heavily dislike the value judgement of “chore”.

▲

Aplikethewatch 12 hours ago | parent | prev | next [-]

Interesting, never knew about git trailers - will have a look!

▲

IshKebab 11 hours ago | parent | prev | next [-]

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?

▲

imiric 11 hours ago | parent | prev [-]

Eh, I wouldn't say it's a waste of bytes. Conventional Commits are useful for many scenarios.

This metadata could also be added via trailers, but most Git UIs don't show them prominently, or at all. So prefixing the subject is still the way to go.

▲

teeray 8 hours ago | parent [-]

I’d rather not hack my process around the deficiencies of someone else’s poor UI choices. As long as the data is stored in a powerful, structured format, you can serve that up in any way that’s sensible to you with `git log` and other shell friends.

	▲	imiric an hour ago \| parent [-]
		That's your prerogative, but a) conventions are not "hacks", and b) the main benefit of CCs are their visibility. If most code forge web UIs and standalone tools don't make this information visible, it's not of much use. `git log` is just one way to surface this information, and "shell friends" can also make "poor UI choices".