This. Instead of making commits time-based (for example once per hour or once per day), make them purpose-based (say, add a database migration in one commit, and change the color of a button in another one). This also makes it easy to cherry-pick or otherwise backport specific changes to different program versions gor example.

I learned this the hard way, I forgot to commit for a single day and got burned really bad when my regression tests failed and I could not trace the issue(it is called source control for a reason). I declared it was more efficient to revert back to the last commit than spend time fixing broken code that I had no fucking clue where it was and the only thing I had to go by was that it happened between two commits with a whole work day between.

More specifically, what's the connection to Reddit?

The image is from a reddit post. You can click on the link to read it if you want.

(Weird, I remember kbin rendering it as an embed...)

For real, or when you should make the first and second commit.
Or worse, when you're too focused and start making a ton of changes, then you realize you haven't committed anything. Discovering I can stage ranges has made me fall for this way too many times, because I think I'll easily just go back and extract one atomic change at a time later (spoiler: it won't be easy ( ; ´ Д `))

as soon as you realize you can't easily contain your commit message within a 50-character conventional message (or slightly more if you wand to be more specific about the scope)