[PATCH] SubmittingPatches: spell out "replace fully to pretend to be perfect"

From: Junio C Hamano <gitster@pobox.com>
Date: Mar 9, 2026, 22:15 UTC
Message-ID: <xmqq34283b12.fsf@gitster.g>

It unfortunately is a recurring theme that new developers tend to pile more "fixup" patches on top of the already reviewed patches, making the topic longer and keeping the history of all wrong turns, which interests nobody in the larger picture. Even picking a narrow search in the list archive for "pretend to be a perfect " substring, we find these:

    https://lore.kernel.org/git/xmqqk29bsz2o.fsf@gitster.mtv.corp.google.com/
    https://lore.kernel.org/git/xmqqd0ds5ysq.fsf@gitster-ct.c.googlers.com/
    https://lore.kernel.org/git/xmqqr173faez.fsf@gitster.g/

The SubmittingPatches guide does talk about going incremental once a topic hits the 'next' branch, but it does not say much about how a new iteration of the topic should be prepared before that happens, and it does not mention that the developers are encouraged to seize the opportunity to pretend to be perfect with a full replacement set of patches.

Add a new paragraph to stress on this in the section that describes the life-cycle of a patch series.

Signed-off-by: Junio C Hamano <gitster@pobox.com>
---
 cf. https://lore.kernel.org/git/xmqqo6kw3bjp.fsf@gitster.g/

 Documentation/SubmittingPatches | 12 ++++++++++++
 1 file changed, 12 insertions(+)

diff --git c/Documentation/SubmittingPatches w/Documentation/SubmittingPatches
index e270ccbe85..f6ec8a3dde 100644
--- c/Documentation/SubmittingPatches
+++ w/Documentation/SubmittingPatches
@@ -43,6 +43,18 @@ help you find out who they are.
   respond to them with "Reply-All" on the mailing list, while taking
   them into account while preparing an updated set of patches.
 
+. 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.  IOW,
+  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).