4 ms·

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

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

matrss 3y ago
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...
- palata 3y ago
  > 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.
  - matrss 3y ago
    > 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.