linux-kernel - [PATCH] SubmittingPatches: add a rule describing how to submit reverted changes

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [day] [month] [year] [list]

Date:	Fri, 25 Mar 2016 20:42:47 +0200
From:	Vladimir Zapolskiy <vz@...ia.com>
To:	Jonathan Corbet <corbet@....net>
Cc:	linux-doc@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: [PATCH] SubmittingPatches: add a rule describing how to submit reverted changes

The change adds a basic formal rule for developers about how to format
subject and commit message of reverted changes.

The rule is based on discussion from
http://www.spinics.net/lists/arm-kernel/msg75667.html :

 RMK> I think it's sensible to keep at least the summary line
 RMK> of a 'git revert' intact rather than inventing our own.

Signed-off-by: Vladimir Zapolskiy <vz@...ia.com>
---

The motivation of this change is to avoid ambiguity and discussions
of the format of reverted changes in future, an example of
such a discussion is found here: https://lkml.org/lkml/2016/3/24/536

On practice only a statistically minor number of accepted reverted
changes has its own duplicated subsystem designator.

 Documentation/SubmittingPatches | 8 ++++++++
 1 file changed, 8 insertions(+)

diff --git a/Documentation/SubmittingPatches b/Documentation/SubmittingPatches
index 8c79f1d..4fff51b 100644
--- a/Documentation/SubmittingPatches
+++ b/Documentation/SubmittingPatches
@@ -670,6 +670,14 @@ that developers understand the order in which the patches should be
 applied and that they have reviewed or applied all of the patches in
 the patch series.
 
+In case if a patch is generated by 'git revert' of some original
+change, the subject should not be edited and it should look like
+'Revert "original summary phrase"', target original subsystem can be
+taken from the original summary phrase, also the commit ID of
+the original change must be specified above the commit text message:
+
+  "This reverts commit <sha1>".
+
 A couple of example Subjects:
 
     Subject: [PATCH 2/5] ext2: improve scalability of bitmap searching
-- 
2.1.4