Re: [PATCH] SubmittingPatches: spell out "replace fully to pretend to be perfect"
On Mon, Mar 9, 2026, at 23:15, Junio C Hamano wrote:
Show 19 quoted lines
> 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/ ?
Show 23 quoted lines
> 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,
Spell out “In other words”.
Show 6 quoted lines
> + 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).