> What's wrong with a big end of day commit?

It's useless for all but the code preservation part, it doesn't tell you anything.

> But then comes somebody and decides to just flush your well curated history down the toilet (=delete it and start somewhere else from scratch) and then all the valuable metadata stored in the history is lost.

I would be very angry if someone deletes my work, why would I accept that? When my colleague throws my work into the bin, I will complain to my superior, they pay me for it after all.

> Maybe consider putting your energy into a good documentation inside the repository. I would love to have more projects with documentations which cover the timeline and ideas during development

That's what commit messages are? They provide the feature that you can click on any line in your codebase and get an explanation, why that line is there, what it is supposed to do, and how it came to be. That's very valuable and in my opinion, much more useful than a static standalone documentation.

First you think of commits as backups, then you think of them as a code distribution. Later you see them as a way to record time. What has been a useful insight to me was, what time is a prerequisite to: causality. Now I see that a VCS is less about recording actual history, but about recording evolution dependency, causality and intent. Also I perceive my work less to be about producing a final state of a codebase, but about producing part of the history of a codebase. My work output is not a single distribution of code, but documented, explainable and attributed diffs, i.e. commits.