Cursed. I had a coworker once would commit diffs like that but always with the message "Cleanup". The git history was littered with "Cleanup" commits that actually hid all kinds of stuff in them. If you pulled them up on it (or anything else) they went into defensive meltdown mode, so everyone on the team just accepted it and moved on.
Back in 1990 or so I worked at a networking company (Vitalink) that was using whatever source control was popular back then. I forget which one, but the important thing was that rather than allowing multiple check outs followed by resolve, that system would lock a file when it was opened for edit and nobody else could make edits until the file was checked in.
One young developer checked out a couple files to "clean them up" with some refactoring. But because he changed some function interfaces, he needed to check out the files which called those functions. And since he was editing those files he decided to refactor them too. Pretty quickly he had more than half the files locked and everyone was beating on him for doing that. But because he had so many partial edits in progress and things weren't yet compiling and running, he prevented a dozen other people from doing much work for a few days.
Eh, when you're hacking away as a solo developer on something big and new I don't think this matters at all. In my current project I did about 200x commits marked "wip" before having enough structure and stability to bother with proper commit messages. Whatever lets you be productive until more structure is helpful.
The code base may go through several almost total rewrites before it stabilizes, especially for non-trivial systems that are performance sensitive. Changes to the code may be intrinsically non-modular depending on the type of software. This prior history can be enormous yet have no value, essentially pure noise.
The efficient alternative, which I’ve seen used a few times in these cases, is to retcon a high-quality fake history into the source tree after the design has stabilized. This has proven to be far more useful to other engineers than the true history in cases like this.
Incremental commits are nice but not all types of software development lends itself to that, especially early in the development process. I’ve seen multiple cases where trying to force tidy incremental commit histories early in the process produced significantly worse outcomes than they needed to be.
That doesn't have a commit history going back to what the parent said about the first 200 commits though. It starts off with basically 3 commits all called some variant of "initial public release", after which good commit messages start, so that probably skipped many intermediate WIP states
I agree that one can do good commit messages also early on though. Initial commit can be "project skeleton", then "argument parsing and start of docs", then maybe "implemented basic functionality: it now lists files when run", next "implemented -S flag to sort by size", etc. It's not as specific as "Forbid -H option in POSIX mode" and the commits are going to often be large and touch different components, but I'd say that's expected for young projects with few (concurrent) contributors
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.
https://github.com/RealNeGate/Cuik/commits/master/