which would match v1 and v2 patches).
Edit your cover letter again. Now is a good time to mention what's different
between your last version and now, if it's something significant. You do not
need the exact same body in your second cover letter; focus on explaining to
reviewers the changes you've made that may not be as visible.
You will also need to go and find the Message-ID of your previous cover letter.
You can either note it when you send the first series, from the output of `git
send-email`, or you can look it up on the
https://lore.kernel.org/git[mailing list]. Find your cover letter in the
archives, click on it, then click "permalink" or "raw" to reveal the Message-ID
header. It should match:
----
Message-ID: <foo.12345.author@example.com>
----
Your Message-ID is `<foo.12345.author@example.com>`. This example will be used
below as well; make sure to replace it with the correct Message-ID for your
**previous cover letter** - that is, if you're sending v2, use the Message-ID
from v1; if you're sending v3, use the Message-ID from v2.
While you're looking at the email, you should also note who is CC'd, as it's
common practice in the mailing list to keep all CCs on a thread. You can add
these CC lines directly to your cover letter with a line like so in the header
(before the Subject line):
----
CC: author@example.com, Othe R <other@example.com>
----
Now send the emails again, paying close attention to which messages you pass in
to the command:
----
$ git send-email --to=target@example.com
--in-reply-to="<foo.12345.author@example.com>"
psuh/v2-*.patch
----
[[single-patch]]
=== Bonus Chapter: One-Patch Changes
In some cases, your very small change may consist of only one patch. When that
happens, you only need to send one email. Your commit message should already be
meaningful and explain at a high level the purpose (what is happening and why)
of your patch, but if you need to supply even more context, you can do so below
the `---` in your patch. Take the example below, which was generated with `git
format-patch` on a single commit, and then edited to add the content between
the `---` and the diffstat.
----
From 1345bbb3f7ac74abde040c12e737204689a72723 Mon Sep 17 00:00:00 2001
From: A U Thor <author@example.com>
Date: Thu, 18 Apr 2019 15:11:02 -0700
Subject: [PATCH] README: change the grammar
I think it looks better this way. This part of the commit message will
end up in the commit-log.
Signed-off-by: A U Thor <author@example.com>
---
Let's have a wild discussion about grammar on the mailing list. This
part of my email will never end up in the commit log. Here is where I
can add additional context to the mailing list about my intent, outside
of the context of the commit log. This section was added after `git
format-patch` was run, by editing the patch file in a text editor.
README.md | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/README.md b/README.md
index 88f126184c..38da593a60 100644
--- a/README.md
+++ b/README.md
@@ -3,7 +3,7 @@
Git - fast, scalable, distributed revision control system
=========================================================
-Git is a fast, scalable, distributed revision control system with an
+Git is a fast, scalable, and distributed revision control system with an
unusually rich command set that provides both high-level operations
and full access to internals.
--
2.21.0.392.gf8f6787159e-goog
----
[[now-what]]
== My Patch Got Emailed - Now What?
Please give reviewers enough time to process your initial patch before
sending an updated version. That is, resist the temptation to send a new
version immediately, because others may have already started reviewing
your initial version.
While waiting for review comments, you may find mistakes in your initial
patch, or perhaps realize a different and better way to achieve the goal
of the patch. In this case you may communicate your findings to other
reviewers as follows:
- If the mistakes you found are minor,