I think I'll disagree with the statement that commit messages are pointless. > Until it starts generating PROFIT, anything else like: clean code, unit testing

I think I'll disagree with the statement that commit messages are pointless. > Until it starts generating PROFIT, anything else like: clean code, unit testing etc, makes zero sense. And also for the record, whenever I'm trying to figure out where something went wrong, commit are not the thing I look at, it's the code changes in the commit. Others have commented on how this reasoning affects the code itself, but I'll ask something different: what about the other 90% of the time, which will be spent on maintenance? How will someone find changesets of interest among others, without looking through the contents of every single commit due to them having no messages, thus removing any chances of them finding the right one based on the message and short circuiting the process? How will they figure out what the other developer was even thinking or trying to do, if the code is decently written, but structurally just odd? After all, your code comments themselves can have references to requirements in whatever change management system you use (e.g. Jira), or even snippets of business requirements and such for what the reasoning is behind that particular code being written in the way it was (code explains HOW, requirements explain WHY), but in my experience more often than not it won't have all of that, and instead you'll only be able to conduct code archeology more successfully by tracing back through commit messages (which ideally will start with an issue identifier), or at least merge/pull requests, which will bring you to the original requirements for any given change, no matter how many years back it was made. Seeing that issue VMP-14221 is related requirements wise to VMP-5661 that was implemented 5 years back and being able to find an erroneously renamed parameter thanks to some commit messages being noticeable in a sea of others (like "VMP-5661 refactor MyBusinessObject to work with VMK links") in that time frame and then inspecting whether the contents of those particular ones match up with what they say they should do, might just make maintenance more tolerable. The only set of circumstances where I think that'd be useless is personal projects, where you'll be the only one working on them and perhaps don't particularly care about the viability of understanding how the code evolved over time, if the projects aren't commercial in nature. Though other times, when you start writing of a commit message, you realize that it would be better to split your changes up in multiple atomic commits, in case you mess up and reverting something might be necessary. Overall, with everything else being realistic (passable but not ideal circumstances), personally I'll take commit messages over no commit messages, ideally with issue identifiers (implying change management systems of some sort are in place).