Merge branch 'jc/doc-wholesale-replace-before-next'

Doc update.

* jc/doc-wholesale-replace-before-next:
  SubmittingPatches: spell out "replace fully to pretend to be perfect"

diff --cc Documentation/SubmittingPatches
index 359f5fb74e699140e5be1ddb90bcaab4930223d7,a8cdd7aba78c0011618d98504090a26546e9d848..d570184ec84998d4828b72bd819a41832b2da893
--- 1/Documentation/SubmittingPatches
--- 2/Documentation/SubmittingPatches
+++ b/Documentation/SubmittingPatches
@@@ -50,12 -42,19 +50,24 @@@ area
    them in an "on top of your change" patch form.  You are expected to
    respond to them with "Reply-All" on the mailing list, while taking
    them into account while preparing an updated set of patches.
 ++
 +It is often beneficial to allow some time for reviewers to provide
 +feedback before sending a new version, rather than sending an updated
 +series immediately after receiving a review. This helps collect broader
 +input and avoids unnecessary churn from many rapid iterations.
  
+ . These early update iterations are expected to be full replacements,
+   not incremental updates on top of what you posted already.  If you
+   are correcting mistakes you made in the previous iteration that a
+   reviewer noticed and pointed out in their review, you _fix_ that
+   mistake by rewriting your history (e.g., by using "git rebase -i")
+   to pretend that you never made the mistake in the first place.  In
+   other words, this is a chance to pretend to be a perfect developer,
+   and you are expected to take advantage of that.  In the larger
+   picture, nobody is interested in your earlier mistakes.  Just
+   present a logical progression made by a perfect developer who makes
+   no mistakes while working on the topic.
+ 
  . Polish, refine, and re-send your patches to the list and to the people
    who spent their time to improve your patch.  Go back to step (2).