I have neither the motivation nor the energy to start an internet argument about it, but I’d like to reassure the casual reader that this post is promoting a minority viewpoint.
The reality is that developers convey intent through pull requests and rarely go through a commit log.
Most people use commits as "ctrl s", which means commit messages are just some dumb shit in the way of me backing up my files.
If comments are often considered harmful because of their lacking quality, why would commit messages be considered helpful when they suffer from similar issues?
Anyway, software development as a whole decided on a pretty stable set of comments that are considered helpful. Commit messages are clearly in there, as well as API elements description.
I have no idea what you're talking about.
Note I'm not arguing for that as a prescriptive state. I think a good commit log is a good thing and can see that there are different ways of getting there.
Sorry but I feel like you have to be just in denial then.
> But even if that were the case, I don't think the majority of commit messages being bad would mean they don't matter.
OK but I think if it's the case it's fair to say hte majority of developers don't agree, whereas you stated it was an industry wide opinion that they are. I think commit messages are mostly stupid and the git UX is absolute trush. Theoretically, if the git UX weren't trash, they could matter, but it is so they don't.
I never claimed to be stating an industry-widr opinion. I was disagreeing based on my own personal experience. Based on upvotes and other comments, it seems I am not alone in this opinion.
They really don’t.
That doesn’t mean they convey it through commit messages either, mind.
But the latter is definitely the worse sin. Having the information in the commit message is much easier to access (especially with a good editor), and it’s way less likely to be lost.
PR discussions are often a trawling mess of historical baggage, if something has been discussed back and forth for 6 months I’m generally a lot more interested in a final summary of the whats and the whys, than having to go through the entire thing every time.
That’s why the NTSB produces reports, they don’t just publish thousands of hours of raw investigation footwork.
Yeah the Linux Kernel tree is _littered_ with those, it's a real pain /s. To be more serious, any workflow that's a tiny bit serious about technical debt will plain reject a PR that's littered with those. I have no problem with rejecting a PR with obvious commits like those. In a professional setting it's vital to keep codebases manageable, especially if those are in the tens.
> The reality is that developers convey intent through pull requests and rarely go through a commit log.
Not really. Pull request are usually a 1:1 mapping with an user story / ticket id / bug id, etc. They might require multiple changes in multiple places with their own reasoning.