patman: Use the Change-Id, version, and prefix in the Message-Id
As per the centithread on ksummit-discuss [1], there are folks who
feel that if a Change-Id is present in a developer's local commit that
said Change-Id could be interesting to include in upstream posts.
Specifically if two commits are posted with the same Change-Id there's
a reasonable chance that they are either the same commit or a newer
version of the same commit. Specifically this is because that's how
gerrit has trained people to work.
There is much angst about Change-Id in upstream Linux, but one thing
that seems safe and non-controversial is to include the Change-Id as
part of the string of crud that makes up a Message-Id.
Let's give that a try.
In theory (if there is enough adoption) this could help a tool more
reliably find various versions of a commit. This actually might work
pretty well for U-Boot where (I believe) quite a number of developers
use patman, so there could be critical mass (assuming that enough of
these people also use a git hook that adds Change-Id to their
commits). I was able to find this git hook by searching for "gerrit
change id git hook" in my favorite search engine.
In theory one could imagine something like this could be integrated
into other tools, possibly even git-send-email. Getting it into
patman seems like a sane first step, though.
NOTE: this patch is being posted using a patman containing this patch,
so you should be able to see the Message-Id of this patch and see that
it contains my local Change-Id, which ends in 2b9 if you want to
check.
[1] https://lists.linuxfoundation.org/pipermail/ksummit-discuss/2019-August/006739.html
Signed-off-by: Douglas Anderson <dianders@chromium.org>
diff --git a/tools/patman/README b/tools/patman/README
index 7917fc8..02d5829 100644
--- a/tools/patman/README
+++ b/tools/patman/README
@@ -259,12 +259,18 @@
unique entries. If omitted, no change log processing is done.
Separate each tag with a comma.
+Change-Id:
+ This tag is stripped out but is used to generate the Message-Id
+ of the emails that will be sent. When you keep the Change-Id the
+ same you are asserting that this is a slightly different version
+ (but logically the same patch) as other patches that have been
+ sent out with the same Change-Id.
+
Various other tags are silently removed, like these Chrome OS and
Gerrit tags:
BUG=...
TEST=...
-Change-Id:
Review URL:
Reviewed-on:
Commit-xxxx: (except Commit-notes)