Hacker News Reader

Comment by nuerow | Hacker News Reader

> This discourages thoughtful and frequent commits that express the intent of a change because all the commits are just smashed together anyway so why bother.

This is only the case if said squashing just bundles commits without context or consistent logic. If merges to a mainline branch consist of feature branches whose pull request was already approved after a couple of iterations then the end result is a cleaner commit with it's history thoroughly audited. In practice it's equivalent to a fast-forward merge of a single-commit feature branch that just happened to be nearly lined up with mainline.

View on HN

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.

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

I mean, it does? If you rigidly turn every feature branch into a single commit, that means that also applies to feature branches that would be thoughtfully crafted into multiple clean commits. (Note: that is not the same as random fixup commits with code review iterations.)

Reply on news.ycombinator.com