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

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

[Junio C Hamano]

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

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

[Kristoffer Haugsbakk]

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

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

[Junio C Hamano]

"Kristoffer Haugsbakk" <kristofferhaugsbakk@fastmail.com> 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 <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).

Thanks for a quick review.