[U-Boot] [PATCH v2] patman: Use the Change-Id, version, and prefix in the Message-Id

[Johannes Berg]

Hi Doug,

> > Actually, the important part for me is to be to be able to have change-
> > ids locally (e.g. for working with gerrit), and not have that leak out
> > to the community (that doesn't like them).
> > 
> > As a maintainer in the community, I'll also need to change the
> > .git/hooks/commit-msg script that comes with gerrit to not add a Change-
> > Id if the commit comes with a Link: tag already, but that should be
> > easy.
> 
> Do you have any idea how to encourage adoption of your git hook?
> Would it make sense to do something like check it in to the Linux
> kernel somewhere?

Not sure, that might backfire completely into getting modified to be a
hook that simply *strips* it, rather than preserving it in the message
ID?

I suspect one thing that might help would be to advertise such a hook
widely where the users are most likely to be, with gerrit? I for one
mostly added this because I need to use gerrit sometimes, and

 (1) stripping the change IDs manually is annoying, and
 (2) stripping the change IDs means I can't actually track my own
     patches

Also, I did in the end modify my commit-msg hook to abort if it finds a
Link:


@@ ... @@
	if grep -i '^Change-Id:' "$MSG" >/dev/null
	then
		return
	fi

+	if grep -i '^Link:' "$MSG" >/dev/null
+	then
+		return
+	fi

	id=`_gen_ChangeId`


and have another hook:

$ cat .git/hooks/applypatch-msg 
#!/bin/sh
. git-sh-setup
# the sfid stuff is sometimes added by my spam filter ...
perl -pi -e 's|^Message-Id:\s*<?([^>]+)>?(\s*\(sfid-.*)?$|Link: 
https://lore.kernel.org/r/$1|g;' "$1"
test -x "$GIT_DIR/hooks/commit-msg" &&
        exec "$GIT_DIR/hooks/commit-msg" ${1+"$@"}
:
(EOF)

that adds the link to patches I pick up from others (since I'm also a
maintainer).

Combined, this means I no longer have to worry about change IDs getting
upstream into my pull requests (that I send out as a kernel maintainer,
if I edit patches I've applied) while I still create them for things I
author locally. This relies on the fact that I even send out my own
patches to the list, and then apply them from there ... at least
usually, to give others any idea.


Anyway, what's the point of all that discussion? I *mostly* did this out
of necessity, to avoid having to manually edit out the change-IDs when I
send patches or when I push code out to kernel.org after editing patches
I've applied from others, but I can still create them locally by default
for the cases where I have to use gerrit.

Not sure if this is the case for many people though, I could just have
used different kernel trees for all those different roles, it's just
harder for me to manage.

Ultimately, to drive adoption, I see two ways

 (1) convince people (other than Linus etc.) that commit tags are
     useful, and those who are convinced can use this stuff to maintain
     it across the kernel workflow (assuming the maintainer uses a
     script such as the apply-msg above, but that seems to be picking up
     adoption)
 (2) show it to those who have a need to work with gerrit or similar
     like me, for whom it covers not sending out the frowned-upon
     change-IDs to the Linux community.

For (1), I guess this should also come with the right commit-msg hook
and the sendemail-validate, since they don't already have the commit-msg 
hook from gerrit.

johannes