Clarify pre-merge commit squash guidance (#43664)
authorKoundinya Veluri <kouvel@users.noreply.github.com>
Tue, 20 Oct 2020 22:29:02 +0000 (18:29 -0400)
committerGitHub <noreply@github.com>
Tue, 20 Oct 2020 22:29:02 +0000 (15:29 -0700)
CONTRIBUTING.md
docs/pr-guide.md

index 9bf8287..a8cf7c3 100644 (file)
@@ -67,10 +67,6 @@ We use and recommend the following workflow:
     - The next official build will automatically include your change.
     - You can delete the branch you used for making the change.
 
-Note: It is OK for your PR to include a large number of commits. Once your change is accepted, you will be asked to squash your commits into one or some appropriately small number of commits before your PR is merged.
-
-Note: It is OK to create your PR as "[WIP]" on the upstream repo before the implementation is done. This can be useful if you'd like to start the feedback process concurrent with your implementation. State that this is the case in the initial PR comment.
-
 ## Up for Grabs
 
 The team marks the most straightforward issues as [up for grabs](https://github.com/dotnet/runtime/labels/up-for-grabs). This set of issues is the place to start if you are interested in contributing but new to the codebase.
index 9074d69..7e1454b 100644 (file)
@@ -27,7 +27,7 @@ Anyone with write access can merge a pull request manually or by setting the [au
 * The PR successfully builds and passes all tests in the Continuous Integration (CI) system.
     * Depending on your change, you may need to re-run validation. See [rerunning validation](#rerunning-validation) below.
 
-Please always **squash** the pull request unless there are special circumstances. Do so, even if the PR contains only one commit. It creates a simpler history than a Merge Commit. "Special circumstances" are rare, and typically mean that there are a series of cleanly separated changes that will be too hard to understand if squashed together, or for some reason we want to preserve the ability to bisect them.
+Typically, PRs are merged as one commit. It creates a simpler history than a Merge Commit. "Special circumstances" are rare, and typically mean that there are a series of cleanly separated changes that will be too hard to understand if squashed together, or for some reason we want to preserve the ability to bisect them.
 
 ## Rerunning Validation