4 ms·
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
by astrobe_ 5y ago
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 5y ago> 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 5y agoWhy would you? Linux (and any other C or Rust open source project I have worked on) compile and work at any commit.
- rectang 5y agoMost 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.