Git development
 help / color / mirror / Atom feed
From: Junio C Hamano <gitster@pobox.com>
To: Karthik Nayak <karthik.188@gmail.com>
Cc: Husain Sitamuwala via GitGitGadget <gitgitgadget@gmail.com>,
	git@vger.kernel.org,
	 Hussain Sitamouwala <husainsitamuwala21@gmail.com>
Subject: Re: [PATCH v2] check-ref-format: use parse-options API
Date: Tue, 03 Nov 2026 10:46:53 -0800	[thread overview]
Message-ID: <xmqq33th92hu.fsf@gitster.g> (raw)
In-Reply-To: <CAOLa=ZS3ULcNVjV1DMO-iB+LcC2Gnw+9oU2_7VXKoLvgiVRnbg@mail.gmail.com> (Karthik Nayak's message of "Tue, 3 Nov 2026 05:00:59 -0500")

Karthik Nayak <karthik.188@gmail.com> writes:

> If you follow our 'Documentation/SubmittingPatches' guidelines, it
> states:
>
>   It is often beneficial to allow some time for reviewers to provide
>   feedback before sending a new version, rather than sending an updated
>   series immediately after receiving a review. This helps collect
>   broader input, gives reviewers in different time zones a fair chance
>   to comment, and avoids unnecessary churn from many rapid iterations.
>   Waiting also encourages you to polish each version before sending it,
>   so reviewers can focus on substantial issues rather than typos or
>   other small mistakes.

Thanks for bringing it up.  Also MyFirstContribution has this:

    After a few days, you may receive comments on your patch series.
    Carefully read them to understand the reviewers' perspective, and do
    not hesitate to ask for clarification.

    Reviewers may also ask about your proposed commit log or the changes.
    Answer these in your response.  They often ask because the patch needs
    clarification; use this feedback to improve your writing, and update
    the patch so the next reader does not have to ask the same question.

    Do not start coding, much less send the next version, until you finish
    discussing the current one and both sides know what to expect.  This
    saves time, lets reviewers respond before you write a patch they have
    to reject, and avoids forcing them to inspect 'v2' only to find their
    concerns unaddressed.

      reply	other threads:[~2026-11-03 18:46 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-10-29 18:33 [PATCH] check-ref-format: use parse-options API Husain Sitamuwala via GitGitGadget
2026-10-29 20:09 ` Junio C Hamano
2026-11-03  8:33 ` [PATCH v2] " Husain Sitamuwala via GitGitGadget
2026-11-03 10:00   ` Karthik Nayak
2026-11-03 18:46     ` Junio C Hamano [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=xmqq33th92hu.fsf@gitster.g \
    --to=gitster@pobox.com \
    --cc=git@vger.kernel.org \
    --cc=gitgitgadget@gmail.com \
    --cc=husainsitamuwala21@gmail.com \
    --cc=karthik.188@gmail.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox