Almost a year ago I wrote my own idea for a convention that could replace Conventional Commits. In this article I’m going to talk about why I did that, and revise the idea as I currently see it. I will not go so far as to formalise a spec in this article, but seeing as the idea draws from existing ideas there probably won’t be very much ambiguity from the start; I say you should be in the clear to use this convention for your new project if you choose to.

The Short Version

If you’re already familiar with the traditional convention and conventional commits, it really doesn’t take much to explain the idea I intend to convey. Here it is by example - all of these are valid in my “Practical Commits” convention:

• dev: use "dev" instead of "refactor"
• Use "dev" as the default for the traditional format
• refactor: use "refactor" only when it’s a refactor

What’s The Point?

Better for contributors

I used conventional commits a lot when I worked at Puter but I got some resistance for it. The primary issue was that the repository was meant to cater to contributors as much as possible, but Conventional Commits isn’t contributor friendly. The moment you tell a contributor they need to change their commit message to get merged, it’s very possible they’re going to lose interest and never respond.

Doesn’t dilute the term “refactor”

Another issue Conventional Commits has is a very general definition of what a “refactor” is. By their definition it is any change that doesn’t change the functional behaviour of the code. I feel it doesn’t match well with the way the term is generally used and understood. A refactor is usually not a small change; it’s one of those necessary but tricky architectural upheavals. It comes from the mathematical concept of factorisation; it involves specifically changing your OOP structure or how methods or functions are composed. There are plenty of code changes that aren’t “features” that I also wouldn’t consider a refactor:

• renaming a method or function
• tweaking parameters
• moving some files around
• rewriting a single function or method

I am not claiming that this is the correct understanding of the meaning of the term “refactor” as it’s generally used, but I definitely think this is the most practical definition of the term.

When You Can’t Subset, At Least Superset™ ²

Conventional Commits is neither a subset nor a superset of the traditional convention for Git commit messages. To show this we only need a proof by contradiction showing that there is at least one traditional commit message that isn’t a valid Conventional Commits message and at least one Conventional Commits message that is not a valid traditional commit message. This is easy because all traditional messages begin with a capital letter making them not valid Conventional Commits messages, and all Conventional Commits messages begin with a lower-cased prefix making them not valid traditional commit messages.

That’s a little over-explained perhaps, but now it’s easier to see how my convention is at least a superset of both:

• Any valid Conventional Commits message is valid in my convention
• Any valid traditional commit message is valid in my convention

It’s not possible to be a subset of both because the spec for Conventional Commits already screwed that up. You could think of my “Practical Commits” convention as being a patch for Conventional Commits that fixes this oversight - it sure makes me feel better to think about it like that.

Addressing An XKCD #927

Every time any convention or standard is proposed it’s important to refer to XKCD #927 (explain link)¹, which describes the natural order of what happens when you create a new standard. It posits that when you create one standard to unify them all, you add to the list of competing standards and inadvertently make the problem worse. Being aware of this, I could not in good conscience promote my convention without having a solid defence that this issue won’t occur. So here’s my defence that this issue won’t occur:

1. There are few competing standards that I’m aware of for Git commit messages. You have:
   1. The Linus → Tim Pope → Chris Beam class of conventions which essentially work together to create the very same convention but just clearer at each iteration. This is the convention you probably use if you’re not using Conventional Commits.
   2. Conventional Commits, which adds structured prefixes to the previous convention. However, it is not a subset of the previous convention. Technically fix: write commits better breaks the rules because it doesn’t Capitalise the first letter in the imperative. Also, a “Linus → Tim Pope → Chris Beam” commit is not a valid conventional commit. That’s right; it’s not a superset either! Talk about an oversight.
   3. There’s Gitmoji, but I feel this should describe what your GUI or TUI should do when displaying commit messages, not what you should actually type in one. We can’t all shell out for a physical emoji keyboard after all.
2. Putting Gitmoji aside, commits written in either convention are compatible with my convention. My convention is a subset of neither, but it is at least a superset of both which at this point seems to be the best we can hope for.
3. I haven’t seen anybody do this yet. I don’t know why, and I’m sure I’m not the only person who has thought of this, but research revealed nothing in this area.

Footnotes

1. I provided both links because explainxkcd.com was actually down when I checked for it.
2. That’s not a real trademark, it’s just a joke. ChatGPT told me I don’t actually need to clarify that, but it also told me I can’t trust it for legal advice.