Hacker News Reader

For me, if a PR introduces a bug and then fixes it later, it must be squashed together. First of all, and most importantly, because it makes it easier for reviewers.

Second, makes no sense to merge, consciously, a bug into master, specially if it's known and fixed already.

View on HN

That's the type of thing I use rebase -i for though. My concern with squashing is that quite often you have multiple stable points in the development of a feature. The order that those states were reached is informative to reviewers and I wouldn't want to make a habit of squashing them away.

I think focusing on committing green test states often leads to faster development and more focused thinking, and I'd prefer to see this approach represented in the final commits rather than getting in the habit of squashing days and days of work into single mammoth commits.

I think you're both talking about the same thing. Basically, if you realize you had a typo somewhere in an early commit, or some other random easily fixable error that you simply overlooked and thus isn't part of the evolution of development, you should use rebase -i to squash the fix commit together with the one that introduced the error.

It's not about squashing together the entire history of development.

:+1:

Reply on news.ycombinator.com