Linux kernel mirror (for testing) git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git
kernel os linux

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 <cmetcalf@ezchip.com>
[jc: moved the added text to a separate section]
Signed-off-by: Jonathan Corbet <corbet@lwn.net>

authored by

Chris Metcalf and committed by
Jonathan Corbet
d7ac8d85 a907c907

+14 -1
+14 -1
Documentation/SubmittingPatches
··· 718 718 See more details on the proper patch format in the following 719 719 references. 720 720 721 + 15) Explicit In-Reply-To headers 722 + -------------------------------- 721 723 722 - 15) Sending "git pull" requests 724 + It can be helpful to manually add In-Reply-To: headers to a patch 725 + (e.g., when using "git send email") to associate the patch with 726 + previous relevant discussion, e.g. to link a bug fix to the email with 727 + the bug report. However, for a multi-patch series, it is generally 728 + best to avoid using In-Reply-To: to link to older versions of the 729 + series. This way multiple versions of the patch don't become an 730 + unmanageable forest of references in email clients. If a link is 731 + helpful, you can use the https://lkml.kernel.org/ redirector (e.g., in 732 + the cover email text) to link to an earlier version of the patch series. 733 + 734 + 735 + 16) Sending "git pull" requests 723 736 ------------------------------- 724 737 725 738 If you have a series of patches, it may be most convenient to have the