diff options
| author | André Fabian Silva Delgado <emulatorman@parabola.nu> | 2016-01-20 14:01:31 -0300 |
|---|---|---|
| committer | André Fabian Silva Delgado <emulatorman@parabola.nu> | 2016-01-20 14:01:31 -0300 |
| commit | b4b7ff4b08e691656c9d77c758fc355833128ac0 (patch) | |
| tree | 82fcb00e6b918026dc9f2d1f05ed8eee83874cc0 /Documentation/SubmittingPatches | |
| parent | 35acfa0fc609f2a2cd95cef4a6a9c3a5c38f1778 (diff) | |
Linux-libre 4.4-gnupck-4.4-gnu
Diffstat (limited to 'Documentation/SubmittingPatches')
| -rw-r--r-- | Documentation/SubmittingPatches | 23 |
1 files changed, 18 insertions, 5 deletions
diff --git a/Documentation/SubmittingPatches b/Documentation/SubmittingPatches index fd89b04d3..d603fa078 100644 --- a/Documentation/SubmittingPatches +++ b/Documentation/SubmittingPatches @@ -659,8 +659,8 @@ succinct and descriptive, but that is what a well-written summary should do. The "summary phrase" may be prefixed by tags enclosed in square -brackets: "Subject: [PATCH tag] <summary phrase>". The tags are not -considered part of the summary phrase, but describe how the patch +brackets: "Subject: [PATCH <tag>...] <summary phrase>". The tags are +not considered part of the summary phrase, but describe how the patch should be treated. Common tags might include a version descriptor if the multiple versions of the patch have been sent out in response to comments (i.e., "v1, v2, v3"), or "RFC" to indicate a request for @@ -672,8 +672,8 @@ the patch series. A couple of example Subjects: - Subject: [patch 2/5] ext2: improve scalability of bitmap searching - Subject: [PATCHv2 001/207] x86: fix eflags tracking + Subject: [PATCH 2/5] ext2: improve scalability of bitmap searching + Subject: [PATCH v2 01/27] x86: fix eflags tracking The "from" line must be the very first line in the message body, and has the form: @@ -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 |