git.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Junio C Hamano <gitster@pobox.com>
To: Jari Aalto <jari.aalto@cante.net>
Cc: git@vger.kernel.org
Subject: Re: [PATCH] Documentation/SubmittingPatches: Instruct how to use [PATCH] Subject header
Date: Sun, 03 Feb 2008 16:55:21 -0800	[thread overview]
Message-ID: <7v7ihlpmkm.fsf@gitster.siamese.dyndns.org> (raw)
In-Reply-To: <r6ft1sd1.fsf@blue.sea.net> (Jari Aalto's message of "Mon, 04 Feb 2008 02:24:10 +0200")

Jari Aalto <jari.aalto@cante.net> writes:

> Suggest putting additional message inside brackets, like [PATCH v2]
> for reworked content.
>
> Signed-off-by: Jari Aalto <jari.aalto AT cante.net>
> ---
>  Idea by Jakub Narebski
>
>  Documentation/SubmittingPatches |    3 +++
>  1 files changed, 3 insertions(+), 0 deletions(-)
>
> diff --git a/Documentation/SubmittingPatches b/Documentation/SubmittingPatches
> index de08d09..69ecbd3 100644
> --- a/Documentation/SubmittingPatches
> +++ b/Documentation/SubmittingPatches
> @@ -37,6 +37,9 @@ Checklist (and a short version for the impatient):
>  	  maintainer (gitster@pobox.com). If you use
>  	  git-send-email(1), please test it first by sending
>  	  email to yourself.
> +        - If you rework the patch, announce the message
> +          in brackets. For example "[PATCH/RFC]", "[PATCH (resend)]",
> +          "[PATCH v2]" etc.
>  

This adds something to the "short version" that the full version
does not even talk about?

I do not think this needs to be in the short version, but an
update to the full version would indeed be a good idea.

diff --git a/Documentation/SubmittingPatches b/Documentation/SubmittingPatches
index de08d09..0661293 100644
--- a/Documentation/SubmittingPatches
+++ b/Documentation/SubmittingPatches
@@ -112,7 +112,12 @@ lose tabs that way if you are not careful.
 
 It is a common convention to prefix your subject line with
 [PATCH].  This lets people easily distinguish patches from other
-e-mail discussions.
+e-mail discussions.  Use of additional markers after PATCH and
+the closing bracket to mark the nature of the patch is also
+encouraged.  E.g. [PATCH/RFC] is often used when the patch is
+not ready to be applied but it is for discussion, [PATCH v2],
+[PATCH v3] etc. are often seen when you are sending an update to
+what you have previously sent.
 
 "git format-patch" command follows the best current practice to
 format the body of an e-mail message.  At the beginning of the

  parent reply	other threads:[~2008-02-04  0:56 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2008-02-04  0:24 [PATCH] Documentation/SubmittingPatches: Instruct how to use [PATCH] Subject header Jari Aalto
2008-02-04  0:29 ` Johannes Schindelin
2008-02-04  8:12   ` Jari Aalto
2008-02-04  0:55 ` Junio C Hamano [this message]
2008-02-04  1:00   ` [PATCH 1/2 (RFC)] Documentation/SubmittingPatches: discuss first then submit Junio C Hamano
2008-02-04  1:02   ` [PATCH 2/2] Documentation/SubmittingPatches: What's Acked-by and Tested-by? Junio C Hamano

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=7v7ihlpmkm.fsf@gitster.siamese.dyndns.org \
    --to=gitster@pobox.com \
    --cc=git@vger.kernel.org \
    --cc=jari.aalto@cante.net \
    /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;
as well as URLs for NNTP newsgroup(s).