From: Kristoffer Haugsbakk Date: Mon, 09 Mar 2026 23:19:52 GMT Subject: Re: [PATCH] SubmittingPatches: spell out "replace fully to pretend to be perfect" Message-ID: <32e7a75c-f8c3-4a2b-8865-ab48330fd4cc@app.fastmail.com> In-Reply-To: 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).