Hacker News Reader

Personally I’m happy with that. If the thing merged caused an issue, I’d want to revert the entire thing that was merged, not a subpart of it which would result in a state of the codebase that nobody reviewed.

If you’re very diligent about making good atomic commits that always pass all test that can work, but I find that squashing PRs (and PRs being relatively small) is a very good trade off

View on HN

Sounds reasonable. Also, when squashing a PR would conflate unrelated commits then maybe those commits should have been separate PRs instead.

I've recently started to like squashing after usually preferring rebase merges, because with squashes I have an easy option to rewrite the commit message and edit out all of those meaningless "fix typo", "improve" and "now actually working" lines...

> I've recently started to like squashing after usually preferring rebase merges, because with squashes I have an easy option to rewrite the commit message

And why couldn't you rewrite the commit messages while rebasing?

EDIT: oh, you mean from the GitHub webUI, I presume. Got it.

> EDIT: oh, you mean from the GitHub webUI, I presume. Got it.

Yes, exactly, while reviewing and merging other peoples PRs. Technically I could still rewrite in other ways, but while squashing in the web UI was the most comfortable workflow.

Reply on news.ycombinator.com