From d7ac8d85d39f460df9204b875eb985e18a5c523b Mon Sep 17 00:00:00 2001 From: Chris Metcalf Date: Thu, 5 Nov 2015 15:21:47 -0500 Subject: [PATCH] Documentation/SubmittingPatches: discuss In-Reply-To Add a paragraph suggesting best practices for when to link patches to previous LKML messages via In-Reply-To. Signed-off-by: Chris Metcalf [jc: moved the added text to a separate section] Signed-off-by: Jonathan Corbet --- Documentation/SubmittingPatches | 15 ++++++++++++++- 1 file changed, 14 insertions(+), 1 deletion(-) diff --git a/Documentation/SubmittingPatches b/Documentation/SubmittingPatches index fd89b04d34f0..0db4e106fbf0 100644 --- a/Documentation/SubmittingPatches +++ b/Documentation/SubmittingPatches @@ -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 +-------------------------------- -15) Sending "git pull" requests +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. + + +16) Sending "git pull" requests ------------------------------- If you have a series of patches, it may be most convenient to have the