This is a mixed bag.

Your changes to mailinfo is fine, and I think it may make even more sense
to also parse out In-Reply-To: and References: to capture the message
context better.

On the other hand, I'd NAK changes to pretty.c and commit-tree.c; it is
wrong to place that information in new commit object header.  The commit
object header is a place to store information common to all commit objects
(authorship and committer) and the structural information that is required
to correctly handle the commit objects (pointers to trees and commits, and
encoding that tells what the message part is in if it is not in UTF-8).

Just like workflows inspired by the kernel project use Signed-off-by: and
Acked-by: information in the commit message part to keep track of the flow
of patches, and some distro folks say "Closes #nnn" in their messages to
close their issue tracking system entries, your "message" is information
only useful to a particular workflow and convention, and belongs to the
commit log message body, not in the object header.

Wouldn't it work equally well to use applypatch-msg hook?  Use your
updated mailinfo to parse necessary information out of the incoming
message, and add Message-ID: to the commit log messsage, perhaps at the
end, in that hook?
--

[ message continues ]

Junio!
Thank you for your response :)


I've found that all I need could be parsed by less changes in mailinfo.



applypatch-msg hook executed on message applying, after that there could be
useful to test applied patch, so it is not the place for notification sending.

-- 
Best regards,
		anton
mailto:agladkov@sw.ru
--

[ message continues ]

And nobody suggested to send anything from the hook.

As I understood from your e-mail without proposed commit log message, your
assumed workflow was:

	receive mail
        "git am" it
	test rewrite amend whatever you want to convince yourself that
         the received patch was Ok
        push the result out
        pushed-into repository has a hook to send notification,
         by picking up the Message-ID from the commit object

The only thing you need was that the message-id information is available
somewhere in the commit object.  I objected to your patch that puts it in
the commit object header and suggested it be placed in the commit log
message.  You can implement such custom commit munging to add an extra
Message-ID: line inside the hook.  You do not have to send out e-mail nor
anything from it.

--

[ message continues ]

I've got your idea! Thank you :)

-- 
Best regards,
		anton
mailto:agladkov@sw.ru
--

[ message continues ]