Process Theater

Recently a colleague of mine introduced “Conventional Commit” to an internal project which surprised me when I saw the CI failure.

I don’t believe the creators of such “spec” have bad intentions. It’s just something that’s easy to be abused for a use case different from the one that it has intended.

I’m even more surprised when I asked if this can be dropped, colleagues, whether they work on this project or not, all chipped in to say yeah we should use it, without giving even one coherent reason to justify it.

To me, this is an ultimate example of a “Process Theater”, where a process is introduced for the sake of having a process, even to the detriment of those involved. It’s Kafkaesque to hear the canned answers.

It helps us to create auto change logs and semver.

This is actually the best argument and one that would have convinced me if we indeed have change logs or semver generated from the commit messages. Currently, there is none and doesn’t seem to be a plan to add one. So we are just following a convention, taking the effort to write something with nothing to read except for the CI checker that checks you have written the thing.

In fact, I’m all for change logs and semver, but it’s unclear whether such a thing when generated from git commits will be useful to the user. I’m sure adding an extra argument to process_documents_return_pairs will really be the great exciting next feature that the user has always been waiting for.

This is industry standard.

Can you back that up with the adoption rate of software engineers of F500 companies?

I have used it for every project.

So?

This is best practice.

Is it? Have you tried to consult the inventor of git and solicit his opinion?

It adds tracebility and auditability, which is required since we are a public company following ISO 9001 …

How does it add tracebility and auditability? We can really prosecute the god damn developer who made a breaking change without marking it as one.

It’s really easy, “feat” for adding a new thing, “fix” for fixing a thing, have you considered reading the spec? The link is just …

No, that’s not how the types are defined. Have you considered reading the spec?

What if I have a feature that’s composed of 20 commits, are they all feats?

Well, if it’s one feature, they should have been one commit. And each commit must be reviewed often.

Guys, I might have discovered something HUGE. Turns out having more than one commit per branch has real use cases! I have a commit that adds a thing and another commit to use the thing. When rebasing to a branch that already adds the thing in a different way, viola, I can drop the first commit and resolve conflicts only for the second commit if at all.

Wow, it’s really unbelievable that the inventor of git totally didn’t intent a branch to have more than one commit and such an accidental feature turns out to be so useful in practice. The mystery still remains that why all branch based forge systems have chosen branches to be the unit for reviewing, not commits. And a bonus point for guessing who is the only guy that has to maintain many feature branches out-of-tree and perform complex rebasing from time to time?

For Gerrit, this makes much more sense, since every commit is required to be an atomic unit that is supposedly easy to rebase on top of any other commit. For a branch based system, it only makes sense for the squash workflow, since only then, a commit is equal to the review unit. From the webpage itself:

Do all my contributors need to use the Conventional Commit specification?

No! If you use a squash based workflow on Git lead maintainers can clean up the commit messages as they’re merged—adding no workload to casual committers. A common workflow for this is to have your git system automatically squash commits from a pull request and present a form for the lead maintainer to enter the proper git commit message for the merge.

Ah, yes, since we are not using the squash workflow (let’s not give people ideas of requiring each MR to be squashed into one commit, merging feature branches to another feature branch is not real and it cannot hurt me!), people must be reasonable and see that it’s meaningless to require it on each commit for a non-squash based workflow, right? Yeah, what if.

Let me think, when tweaking an LLM prompt, I used to have prompt: as a type for the commit message. Apparently this makes no sense since tracing every changes to the prompt is overrated. And we must know if the interface has changed or not. Wait, the prompt asked the LLM to call a new tool, it must be feat. But wait, the LLM wasn’t calling the tool before, it should be fix instead. But wait, the interface hasn’t changed, are you sure it’s not a chore? But wait, the tool turns out to be buggy, and it’s not caught before since it’s not called, so it’s actually a test.

The inherent contradiction for Conventional Commit is that git commit messages are ultimately for developers. Bending it to do a different thing is unavoidably risky and requires careful thinking about the condition to apply and the trade-off, which I know is definitely a thing that people consider when they introduce a new process.

It can be useful, for example, for public libraries. Having a convention can help maintain consistency among a large number of heterogeneous developers. And the most important aspect of the repo is its public interface.

But unfortunately such conditions are almost never presented. Each process wants to present itself as a universal solution that NEEDS to be adopted at all time. And Process Theater people love this. Since having a process doesn’t have to have meaning. It’s comforting, going through the trouble. It soothes the itching to do things, useful or not, anything at all. The sacrifice is the point.

That’s why for an application repo, with only two main contributors, and a non-squash workflow, with no user ever going to see the automatic change log that doesn’t exist, it’s required that every commit message to have a specific format.

It has electrolytes after all.