Subject: Re: [PATCH 0/3] add a message-id header to git

From: James Bottomley <[email-masked]>
Date: Thu, 16 Oct 2025 17:00:40 -0400

On Thu, 2025-10-16 at 13:32 -0700, Junio C Hamano wrote:
> James Bottomley <[email-masked]> writes:
> 
> > There has been some debate in the kernel community about how to
> > link commits back to email, which is the basis of a lot of
> > scripting we do
> > 
> > https://lore.kernel.org/ksummit/[email-masked]/
> > 
> > However, this problem is one that goes beyond the kernel, so having
> > git always track the message-id of the email used to create the
> > commit will be useful beyond our tools as well.  The design of this
> > message-id header is that it never shows up except in --pretty=raw
> > output, so it will never be ordinarily visible, but can be
> > extracted by scripts.  Some projects use the -m flag of git-am to
> > add the Message-Id to the trailers and for backwards compatibility,
> > this functionality is not changed although it is hoped that it is
> > now redundant.
> 
> I am perfectly fine with mailinfo changes and it is OK to add it to
> commit trailer, but to the commit object header?  Having to maintain
> an extra header is a headache, in that you have to worry about what
> rebases and cherry-picks would do to them.  Please don't.

My assumption was that any extra headers in the git object get carried
over, but if I need to do something to make that happen, then I can
certainly craft patches.

The reason for doing it as a header is just for it to be always there
for email workflow.  The trailer doesn't have the same property because
people forget to add it and Linus hates it and refuses to allow it in
kernel code.  I'm hoping the ubiquity will make up for the pain of
adding another header.

> I haven't carefully read [2/3] yet, but do we now forbid to run the
> poor-man's rebase "git format-patch ... | git am" pipeline by
> insisting that state->msg_id to exist in parse_mail()?  The output
> of format-patch over existing commits may not have the message-id
> headers.

So this one's a bit more deliberate.  If you import email and then re-
send as email we can't keep the same message-id; the internet RFCs
require us to keep message-ids unique, so git-format-patch won't output
the message-id.  That necessarily also means that the poor man's rebase
you cite above will still run, but it would drop the message-id header.

Regards,

James