> This is when you believe that your program should at the very least compile (or pass tests) at any point in the history.
I only expect that at merge commits, which I can see with `git log --merges`.
Why would you? Linux (and any other C or Rust open source project I have worked on) compile and work at any commit.
Most of the time, that's what I expect. However, sometimes when proceeding step-by-step through a large refactor or a large feature addition, the codebase may be left temporarily in an incomplete state.
My preference under such circumstances is to favor clarity of commit history, and leave the step-by-step commits intact — with the requirement that they always be located in a feature branch behind a merge commit.
In other words, a commit to us is sort of like an "atomic" change, something that cannot be split or else more or less bad things happen.
I have trouble conceiving a better way to use Git when you really care about the readability of your history. in some cases I don't care about readability though. On hobby projects I sometimes use Git more like a file transfer and synchronization tool. In this case I don't give a huck about how the history looks like.
Just like with code, the more readable this history is (in terms of what features/fixes are in there at some point in time), the better.