undefined | Better HN

0 pointsastrobe_4y ago0 comments

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.

0 comments

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

bonzini4y ago

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

rectang4y ago

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.

j / k navigate · click thread line to collapse

0 pointsastrobe_4y ago0 comments

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.

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.

0 comments

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

bonzini4y ago

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

rectang4y ago

j / k navigate · click thread line to collapse