[nuerow]

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

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

[Vinnl]

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