Re: [Ksummit-discuss] [MAINTAINERS SUMMIT] Patch version changes in commit logs?

["Theodore Ts'o" <tytso@mit.edu>]

On Tue, Jul 02, 2019 at 04:04:31PM -0700, Kees Cook wrote:
> > Step 1)   git config am.messageid true
> 
> This is a lossy action: we don't know which list the ID came from (e.g.
> many things are sent to subsystem lists and not lkml).

Why do we need to care which list the ID came from?  Many messages are
cc'ed to multiple lists that are archived on lore.kernel.org.  And it
doesn't matter:

	lore.kernel.org/r/<message-id>

... will work without needing to know which list it was sent to.

> > Step 2)   Write and install a .git/hooks/applypatch-msg script which
> > 	  looks for Message-Id: and transmogrifies that line to a
> > 	  Link: trailer, using the lore.kernel.org URL template
> 
> I think the lorifier.py[1] mentioned earlier has 90% of the "step 2"
> logic, including caching the lore list mappings. Is there a "git am" hook
> we could build on instead? /me looks. Yes; seems to be "applypatch-msg"?
> Unclear if the email headers are included...

applypatch-msg is the git hoook I had suggested above.

The documentation states:

    This hook is invoked by git-am[1]. It takes a single parameter,
    the name of the file that holds the proposed commit log
    message. Exiting with a non-zero status causes git am to abort
    before applying the patch.

    The hook is allowed to edit the message file in place, and can be
    used to normalize the message into some project standard
    format. It can also be used to refuse the commit after inspecting
    the message file.


That to me says the e-mail headers have already been stripped.
Fortunately, using am.messageid=true should work since that is part of
the proposed commit message.

					- Ted