Useless? Come on. Documentation is hard, and I suspect rather than admit something is hard we'd just rather pretend that "it's not important." > Requiring comm

Useless? Come on. Documentation is hard, and I suspect rather than admit something is hard we'd just rather pretend that "it's not important." > Requiring commit messages is a vestige of engineering practices from the ancient times of the mid-aughts. I know it's been ~20 years, but hardly ancient. I suppose it's ancient to the young? > With modern trunk-based engineering, pull request branches are squash-merged onto main — and all those silly commit messages are thrown out in the process. I do work that way; but those commits are still preserved in git history on the branch I cut the PR from. People have gone back and read them! They've told me as much! But also worth noting that this is a very github/gitlab-centric workflow; certainly the kernel devs don't work that way. > You shouldn’t have to show your work like you did in school. Commit messages aren't for showing your work, they're for explaining why you did what you did at a given point. --- Honestly, in some ways I kinda see the point. But if you're not disciplined enough to squash your damn commits on your branch and re-write messages as-needed there, I just don't believe you're disciplined enough to write good PR messages. The author alludes to this when talking about how the real good stuff is captured in slack, google docs, etc. (all infinitely less-discoverable, especially as time marches on... but I digress). And if you aren't disciplined to write good PR messages either, then who really cares what your git history looks like at that point. I work with and have worked with a lot of engineers with this general mindset - "the real information is in a meeting doc" or whatever - and it honestly sucks. Systems are less reliable, work is of poorer quality, lots of unnecessary work gets done, etc. It's a bad way to do engineering, and there's no other way to put it.