Suggestion: Changing PR Merge Strategy to "Squash and Merge" from "Rebase and Merge"

[Calebsakhtar]

I just wanted to float this idea since I find it occassionally difficult to resync with the main branch in my fork. I recognise that this change would require smaller PRs with fewer commits to be able to debug effectively. However, I don't think this poses too much of a problem.

What do others think?

[speth]

It seems like the current approach has mainly been to use merge commits. My preference in other projects is to maintain a more linear project history by using either "rebase and merge" or "squash and merge". I think which is better depends on whether committers are putting some effort into commit messages, keeping each commit within a PR atomic, and squashing minor changes within a PR. If that's the case, I think "rebase and merge" is better since it preserves this history, and is what I would recommend as the default practice. That said, there can be cases where a PR has a messy history that isn't worth cleaning up on its own, and then squashing the entire PR is the pragmatic thing to do.

[sdeastham]

Very open to this (and thanks for starting this discussion!). My thinking had been that we should transition to "squash and merge", on the basis that it is relatively straightforward to do and relies less on the committers being neat. That's probably too low a bar, but I do appreciate the pragmatism. Reading through this rather ill-tempered thread has made it clear that just about the only wrong strategy is merge commits, so certainly we shouldn't do that as standard any more (at least without requiring more rigour in the PRs - especially my own..).