Squash commits

[elharo]

Update the rules to what we actually ask committers to do

Description

Update the rules to what we actually ask committers to do

Motivation and Context

Multi commit PRs are not allowed in practice

Impact

none

Test Plan

CI

Contributor checklist

• Please make sure your submission complies with our development, formatting, commit message, and attribution guidelines.
• PR description addresses the issue accurately and concisely. If the change is non-trivial, a GitHub Issue is referenced.
• Documented new properties (with its default value), SQL syntax, functions, or other functionality.
• If release notes are required, they follow the release notes guidelines.
• Adequate tests were added if applicable.
• CI passed.

Release Notes

== NO RELEASE NOTE ==

[tdcmeehan]

I would add a little bit of nuance here. "Multi commit PRs are not allowed in practice" is not true. A recent counter-example is #22386. Rather than splitting this up into multiple PRs, @rschlussel did it as one PR with multiple commits. Either is acceptable. "Update the rules to what we actually ask committers to do" is more accurately worded as "what we usually ask committers to do".

Because most people don't write PRs like #22386 anymore, I would encourage perhaps writing instructions that speak to the 95%+ of PRs that actually should be squashed into one commit, and then leaving the existing information for the smaller number of PRs that actually require multiple commits. It seems like that would solve the problem, which is that people may read information about commit ordering which is not relevant to them, and we would like to prioritize the most important and relevant information first.

Alternatively, we could just debate turning on squash commit upon merge in Github, and update the rules. I think there's a lot of merit to doing that, but I think we should have the debate before we update the documentation.