I hate commit linter

06.09.2023, to see all post click here.

As the title says: I hate commit linter. I don't hate the project per se, but I hate that I have already been working for 2 companies that forced it into pre-commit.

What is a good commit message?

In my opinion good commit message answers one question: why did you change those files? Everything else is already contained in the commit itself. So when I write the commit message I try to focus only on that question - add ticket number, post some of the context etc. But with commit linter the first thing I need to do is focus on the format of the message. Unless you are trying to use the messages in some other way (changelog) I simply don't see the benefit.

Whats the point if you gonna squash it anyway

Frequently I take a big issue and work on it solo for few days / weeks. I still commit my work daily - mostly to get CI/CD and potentially to get opinion of other developers. But a lot of my commits messages make sense only within the context of the other commits. The unit of work is the pull request - not the commit. Its the PR that gets reviewed, not the commits. So most of the times I prefer to squash my commits because the PR has answers why the files were changed. And if I am squashing my commits its a bit meaningless to care about the individual commit messages.

It would be helpful if git had pull request built in - that way you could see that commit was part of a pull request - and you would be able to see both the commit and pull request message.

Just one little improvement

At one of my previous contracts I joined a new team working on a legacy app. When I joined the pre-comit and CI/CD was pretty reasonable - black and pytest. But then couple more people joined and everyone wanted to add their favourite tool - suddenly we had isort, autoflake and few more. All of these hooks have their costs - before it would take few secs to commit, after those changes the commit took easily a minute or two - so naturally i would often skip them locally and let the ci/cd message me about failures. I would only fix them once I wanted to the PR to be ready for review.

But the most stupid thing was pre-commit hook that checked for "fixme: " comments. Code with fixme's was not allowed to be merged into master. I guess the idea was that unfinished work should not make into production... But in reality fixme comments are used because

1. the developer has a working thing that is not exactly kosher but
2. does not have enough time to fix it right now

So what happens when you ban the comment from being merged? Do people fix their code when they dont have time to do it? No. They just delete the comment and you end up having the same shitty comment but now you dont even know it was meant to be fixed.