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%7Cg;' "$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