Leaving off the git tag, as I think this is more relevant to programming and version control in general, but will adjust if people feel strongly.
I don’t think he commits too much, and I have gotten the same feedback about my commit habits.
One reason he didn’t mention though is that by committing often you also make sure that if your IDE crashes (looking at you, Visual Studio), you have a backup of your work.
Visual Studio doesn’t save to disk frequently? Before my IDE auto-saved, part of my muscle memory was to hit the ‘Save’ key combo any time I paused to think. If I wrote a commit for every habitual save, that git history would be terrible.
Even when I do write larger things, I try to keep them split into logically separate commits for a lot of the same reasoning of the author. git add -p is your friend (or picking using a visual tool if it’s really hairy).
I view large commits with suspicion - I do think it’s reasonable to squash/fixup junky commits like “Typo fix”, but otherwise I really like having a more-granular history. Makes cherry picking, blaming, and generally anything to do with the history easier to understand.
The crashes I have experienced with Visual Studio is more along the lines of: Get latest from TFS server, Visual Studio hangs, crashes, restart Visual Studio. Changes are gone/clobbered, everything is in a broken state. Get Latest again, changes are still gone but the codebase is fixed again. Hopefully you weren’t working on anything important.
So every time I make a change large enough to describe, I check it in.
This reminds me so much of running ProjectBuilder on Yellow Box on Windows, as well as early Eclipses and stuff. Code save code save code save code dammit. Really interesting that since I gave up using IDEs and just use vi, this is no longer any kind of an issue :-)