Hacker News Reader

Comment by CamouflagedKiwi | Hacker News Reader

I disagree. It's a nice property that every commit in master is (conceptually) fully buildable & all tests passed. I've not found much benefit from having heaps of tiny commits and trying to work out their state; also cherry-picking (if needed) is simple with squash commits, but extremely difficult without.

View on HN

That's why they said this:

> If you make a meandering series of commits during development, squash them for the PR. But please, please do not squash the entire feature upon merge.

I typically turn my PRs into a series of buildable and testable commits. I also put a lot of work into making those commits tell a useful story to the reviewer and to anyone doing git blame later, and squashing them all into one commit undoes that work.

Buildable and testable, but notably sometimes not formatted or linted, when (atypically but not rarely) the semantic change is much easier to understand separated from the superficial changes it motivates in the context of the formatting/linting rules of the project.

Yep. And in a similar vein, not squashing allows you to separate a file move from changes to it so that git can track the move.

Of course all commits should be buildable and pass tests. There’s a scale between ”heaps of tiny commits” and ”squash everything”.

All commits that will be shared. There's nothing wrong with a local WIP commit when you want to plant a flag to compare your next changes against.

Reply on news.ycombinator.com