[astrobe_]

Agreed. This is when you believe that your program should at the very least compile (or pass tests) at any point in the history. In this case a commit must be a consistent and related set of changes.

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.

[rectang]

> 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`.

[bonzini]

Why would you? Linux (and any other C or Rust open source project I have worked on) compile and work at any commit.

[rectang]

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.