Documentation/SubmittingPatches: discuss In-Reply-To
authorChris Metcalf <cmetcalf@ezchip.com>
Thu, 5 Nov 2015 20:21:47 +0000 (15:21 -0500)
committerJonathan Corbet <corbet@lwn.net>
Wed, 11 Nov 2015 17:06:00 +0000 (10:06 -0700)
Add a paragraph suggesting best practices for when to link patches
to previous LKML messages via In-Reply-To.

Signed-off-by: Chris Metcalf <cmetcalf@ezchip.com>
[jc: moved the added text to a separate section]
Signed-off-by: Jonathan Corbet <corbet@lwn.net>
Documentation/SubmittingPatches

index fd89b04d34f038bafd1485a8f96869828470f619..0db4e106fbf027e0b063fc4497eeb418d2936256 100644 (file)
@@ -718,8 +718,21 @@ generates appropriate diffstats by default.)
 See more details on the proper patch format in the following
 references.
 
+15) Explicit In-Reply-To headers
+--------------------------------
+
+It can be helpful to manually add In-Reply-To: headers to a patch
+(e.g., when using "git send email") to associate the patch with
+previous relevant discussion, e.g. to link a bug fix to the email with
+the bug report.  However, for a multi-patch series, it is generally
+best to avoid using In-Reply-To: to link to older versions of the
+series.  This way multiple versions of the patch don't become an
+unmanageable forest of references in email clients.  If a link is
+helpful, you can use the https://lkml.kernel.org/ redirector (e.g., in
+the cover email text) to link to an earlier version of the patch series.
+
 
-15) Sending "git pull" requests
+16) Sending "git pull" requests
 -------------------------------
 
 If you have a series of patches, it may be most convenient to have the