Re: [RFC PATCH 2/2] doc: advise batching patch rerolls

From: Junio C Hamano <gitster@pobox.com>
Date: Jun 13, 2026, 16:02 UTC
Message-ID: <xmqqwlw2e8dc.fsf@gitster.g>
In-Reply-To: <8166623d1599fca2cd4614889e4a69b2006c12c1.1781358364.git.wy@wyuan.org>

Weijie Yuan <wy@wyuan.org> writes:

Show 7 quoted lines

> Contributors often need guidance on how quickly to send later iterations
> of a patch series. Add a rough default of no more than one new version
> of the same series per day so feedback can be batched and reviewers have
> time to comment.
>
> Mention factors that can affect the timing, such as series size, review
> depth, substantial rework, and how close the topic is to being accepted.

Another good thing to discourage yourself from rerolling too quickly is that such a practice forces you to think twice and be very careful before sending patches out. As you have only one chance to get it right before, say, 24 hours, you'd want to make sure that you would not distract your reviewers with stupid typoes, off-by-one errors, and such, and concentrate their reviews more on what matters more, i.e., the higher level design, choice of algorithms, etc.

Show 6 quoted lines

> +This consideration applies not only when going from the initial patch to v2, but
> +also to later iterations of the same series. There is no fixed rule for how long
> +to wait before sending a new version. A useful default is to send at most one
> +new version of the same patch series per day. This gives multiple reviewers time
> +to comment, lets you batch feedback together, and gives you time to think
> +through the comments you received.

And the 24-hour gives equal chance to comment on your patches to anybody no matter where they live ;-)

I see you CC'ed Patrick, and I am sure he'll give us more useful suggestions than I do here ;-)

Thanks.