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

> 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 <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”.
>
>> +  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).