global/git
1
0
Fork 0
mirror of https://github.com/git/git.git synced 2026-03-11 09:29:49 +01:00
Code Issues Packages Projects Releases Wiki Activity

SubmittingPatches: spell out "replace fully to pretend to be perfect"

Browse Source 
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 this point in the section that
describes the life-cycle of a patch series.

Signed-off-by: Junio C Hamano <gitster@pobox.com>
This commit is contained in:
Junio C Hamano
2026-03-09 15:15:05 -07:00
parent 67ad42147a
commit 476365ac85
1 changed files with 12 additions and 0 deletions
Download Patch File Download Diff File Expand all files Collapse all files

12
Documentation/SubmittingPatches
View File

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