Recent searches
Search options
Hot take: yes, many software engineers write *terrible* commit messages, but the "Conventional Commits" rules are no help at all.
What is? Valuing clear writing, and caring about your collaborators.
("A foolish consistency is the hobgoblin of little minds." -Emerson)
@sanityinc we’re sticklers for patterns and love to solve easy problems that don’t exist.
Cargoculting practices so we don’t have to think is a tradition in our industry. How dare you try to change that! 
@jcf @sanityinc Wow, can't agree more!
Suddenly, everybody became this "we need a rule for commits and clean git history" and, honestly, I never saw somebody who did audit commits like people are saying they do...
What I _did do_ a lot was bisect, which is becoming more and more useless as people rebase/squash multiple small commits into a single "feature" one with 4k changes...
@mauricioszabo @jcf I helped with an OSS repo where the creator then added pedantic pre-commit rules and failed GitHub Actions if PRs didn't have titles in the right format, and the whole thing made me nope out
@mauricioszabo @jcf @sanityinc I really don't understand squash merging. Okay people want to hide the contortions the branch went through to become viable, but so much of the reasoning for things is lost to future debuggers with a squashed merge.
@mathw @jcf @sanityinc Exactly my thoughts.
People complain that they'll do a "git blame" and see something like WIP - Second Try" and that will give no meaning. I hardly disagree - if I'm looking at a piece of code that's weird, and I see this message, I'll be **sure** that it was not "engineered" to be that way.
Compare with "feat: login with OAuth". Yes, that gives meaning, but not about _that specific line_ - which usually is what I'm looking for when I do a blame...
@mauricioszabo @jcf @sanityinc Also if people are that bothered by it they need to write better commit messages. And lose their sense of embarrassment because we all have to make 'oops' commits when something breaks on the build pipeline for whatever reason.
@sanityinc I found it odd, but not surprising, that people end up with commit messages written to be easily parsed for bots, but not for humans. The code changes are the “what” for the computers, the commit message is the “why” for humans.
You have a problem. "I know," you think, "I'll set up some rules for commit messages." Now you have two problems.
I think the only real but slow way to fix this is to get more people reading commit messages.
cc @llimllib
@akkartik @sanityinc I like conventional commits, and I like squash merging, which makes me unpopular in this thread!
@llimllib @akkartik Unpopular? No. There are adequate workflows where you prefer or accept a messy working branch but want a tidy main branch, so squashing isn't unreasonable in that case. But I personally value and prefer a careful (but still concise) commit narrative even in a working branch, and I'd say conventional commits and squash merges obscure and erase that narrative respectively.
@sanityinc Yes exactly.
@llimllib I was curious if you've had to put up with pedantic commit checking in the past.
I wonder if there's a vicious cycle here: pedantic commit message rules -> lack of sense of ownership over commit messages -> minimize commit messages using squashing -> nobody reads them.
The virtuous cycle I got into thanks to http://akkartik.name/codelog.html: read commit messages -> write messages -> appreciate history as a rich source of places where one can provide context.
@akkartik @sanityinc I started writing a blog post about this, but I don't know that I'll finish!
At my current job, when I started, each commit to each PR had to follow conventional commits, and I found that very irritating and pedantic. Then the squash commit didn't have to follow any rules, which led to a lot of crap in the history.
So I convinced everyone to switch it: commit whatever the heck you want to your feature branch, review the PR as a whole, then the merge commit needs to..
@akkartik @sanityinc follow the pedantic rules, and you should lavish some time and care on the merge commit message, as that's what will live on in the future.
My *least* favorite feature of github's PR flow is that you don't review the commit message! I find gerrit generally extremely fussy, but I really like that feature of it, that you're reviewing the commit message as well as the code.
So sometimes, we'll spend a lot of time in PR review, get great explanations, and then somebody just...
@akkartik @sanityinc won't put any of it in the commit message, which frustrates me.
But overall it's a pretty good process that goes well with the grain of the github PR flow, which isn't ideal but is mostly fine enough.
@llimllib That's really interesting. I've been playing with Pijul recently, which performs merges without creating automatic commits. Manual conflict resolution is a separate commit, and my commit message there is invariably just "resolve conflicts".
This is a new "place" I'm not used to having. And I'm using it suboptimally, missing opportunities to provide context: https://pijul.zulipchat.com/#narrow/stream/270693-general/topic/Commit.20messages.20when.20resolving.20conflicts/near/425840943
@llimllib @sanityinc
So I now see the tension more clearly:
- I focus on the authoring process, craft commits as crystalline units of perfection, treat review process as overhead[1] and merge commits as vestigial.
- You focus on the review process, often see creative benefits from it, emphasize the lessons learned in a good merge commit message. The initial commits are just a way to get the conversation started. Their messages are overhead.
[1] I think I haven't been exposed to healthy code review process. Google reviews were d**k-measuring fodder for promo packets and likely put me off the whole idea. These days I tend to focus on irreversible decisions during review but otherwise try to get out of the way during code review. Most things can be adjusted using future commits.
@sanityinc Oh, some context for you. The reason I tagged @llimllib is https://merveilles.town/@akkartik/111859196193506562 This thread has really leveled up the debate, thank you!