Since the project's inception, we've required merge commits and have asked contributors to keep full commit histories in their PRs, rather than rebasing everything to a single, atomic commit. The reason is sound: we want to keep around the full history of PR development because it's often much more useful to explaining why/how a feature was implemented than a simple commit message. However, it does have its downsides, like more commits in the history, intermediate states that won't build or pass tests, etc. Additionally, workflows like stacked Git are increasingly popular. (Stacked Git support is even coming to GitHub soon.)
I believe that if we switch to squash commits, PRs will still maintain the history of commits, so long as we adopt a policy of no force pushes. The review comments are arguably just as important as the sequence of commits, and those are only visible in the PR threads, anyway. So perhaps we should switch to this model.
Since the project's inception, we've required merge commits and have asked contributors to keep full commit histories in their PRs, rather than rebasing everything to a single, atomic commit. The reason is sound: we want to keep around the full history of PR development because it's often much more useful to explaining why/how a feature was implemented than a simple commit message. However, it does have its downsides, like more commits in the history, intermediate states that won't build or pass tests, etc. Additionally, workflows like stacked Git are increasingly popular. (Stacked Git support is even coming to GitHub soon.)
I believe that if we switch to squash commits, PRs will still maintain the history of commits, so long as we adopt a policy of no force pushes. The review comments are arguably just as important as the sequence of commits, and those are only visible in the PR threads, anyway. So perhaps we should switch to this model.