went to write exactly that. Ambitions are great and I dont want to be dissuasive, but monumental tasks require monumental effort and monumental effort requires monumental care. That implies good discipline and certain "beauty" standards that also apply to commit messages. Bad sign :)
Not really. In the initial phase of a project there is usually so much churn than enforcing proper commit messages is not worth it, until the dust settle down.
Many times it is “threw everything out and started over” because the fundamental design and architecture was flawed. Some things have no incremental fix.
I am deeply suspicious of anyone who doesn't bother or who is unable to explain this churn. For the right kind of people, this is an excellent opportunity to reflect: why is there churn? Why did the dust not settle down? Why was the initial approach wrong and reworked into a new approach?
I can understand this if you are coding for a corporate. But if it's your own project, you should care about it enough to write good commit messages.
None of the above. My objection is the lack of explanation.
Churn is okay. Prototypes are okay. Toying with ideas is okay. They should all be in the source tree. But I would want an explanation for the benefit of future readers, including the future author. Earlier in my life I have more than once run blame on a piece of code to find myself writing a line of code where the commit message does not explain it adequately. These days it's much rarer because I ask myself to write good commit messages. Furthermore the act of writing a commit message is also soothing and a nice break from writing for computers.
Explain how requirements have changed. Explain how the prototype didn't work and led to a rewrite. Explain why some idea that was being toyed with turned out to be bad.
Notice that the above are explanations. They do not come with any implied actions. "Why is there churn" is a good question to answer but "how do we avoid churn in the future" is absolutely not. We all know churn is inevitable.
For single-author quickly-changing projects I'd guess that it's quite likely for only like 1% of the commits to be looked at to such extent that the commit message is meaningfully useful. And if each good commit message takes 1 minute to write (incl. overhead from the mental context switching), each of those uses better save 100 minutes compared to just looking at the diff.
I suspect you have never worked on single-author projects where you fastidiously write good commit messages. If you never got into the habit of writing good commit message, you won't find them valuable at all when you are debugging something or just wondering why something is written in a certain way. Once you consistently write good commit messages you begin to rely on them all the time.
"why something is written in a certain way" most likely doesn't even have an answer while a project is still in the rewrite-large-parts-frequently stage. Sure, you could spend some time conjuring up an explanation, but that's quite possibly gonna end up useless when the code is ruthlessly rewritten anyway.
That said, specific fixes or similar can definitely do with good messaging. Though I'd say such belongs in comments, not commit messages, where it won't get shadowed over time by unrelated changes.
And for your average backup system it's only like 1% of backups you need to be able to restore, probably much fewer. Trouble is, your won't know which ones ahead of time - same for commits.
