From: Junio C Hamano Date: Mon, 09 Mar 2026 23:26:40 GMT Subject: Re: [PATCH] SubmittingPatches: spell out "replace fully to pretend to be perfect" Message-ID: In-Reply-To: <32e7a75c-f8c3-4a2b-8865-ab48330fd4cc@app.fastmail.com> "Kristoffer Haugsbakk" writes: > On Mon, Mar 9, 2026, at 23:15, Junio C Hamano wrote: >> 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 > > s/stress on this/stress this point/ ? > >> the life-cycle of a patch series. >> >> Signed-off-by: Junio C Hamano >> --- >> 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, > > Spell out “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. >> + > > Looks good. > >> . 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). Thanks for a quick review.