public inbox for git@vger.kernel.org 
 help / color / mirror / Atom feed
From: James Bottomley <James.Bottomley@HansenPartnership•com>
To: Junio C Hamano <gitster@pobox•com>
Cc: git@vger•kernel.org
Subject: Re: [PATCH 0/3] add a message-id header to git
Date: Thu, 16 Oct 2025 17:00:40 -0400	[thread overview]
Message-ID: <7205e71da08f22db757b5dc0bcf3fef27db40ea4.camel@HansenPartnership.com> (raw)
In-Reply-To: <xmqqfrbi37v6.fsf@gitster.g>

On Thu, 2025-10-16 at 13:32 -0700, Junio C Hamano wrote:
> James Bottomley <James.Bottomley@HansenPartnership•com> 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/a7878386f3546ba475cdf7250ab4f5a6af2a1676.camel@HansenPartnership.com/
> > 
> > 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


  reply	other threads:[~2025-10-16 21:00 UTC|newest]

Thread overview: 14+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-10-16 18:57 [PATCH 0/3] add a message-id header to git James Bottomley
2025-10-16 18:57 ` [PATCH 1/3] mailinfo.c: always collect the message-id James Bottomley
2025-10-16 18:57 ` [PATCH 2/3] builtin/am.c: add a message-id commit header James Bottomley
2025-10-16 22:41   ` brian m. carlson
2025-10-16 18:57 ` [PATCH 3/3] t4150-am: add a test for message-id header collection James Bottomley
2025-10-16 19:26 ` [PATCH 0/3] add a message-id header to git Kristoffer Haugsbakk
2025-10-16 20:10   ` James Bottomley
2025-10-16 20:31     ` Kristoffer Haugsbakk
2025-10-16 20:32 ` Junio C Hamano
2025-10-16 21:00   ` James Bottomley [this message]
2025-10-16 21:18     ` Junio C Hamano
2025-10-16 21:28       ` Kristoffer Haugsbakk
2025-10-16 21:50 ` Kristoffer Haugsbakk
2025-10-16 22:15   ` Junio C Hamano

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=7205e71da08f22db757b5dc0bcf3fef27db40ea4.camel@HansenPartnership.com \
    --to=james.bottomley@hansenpartnership$(echo .)com \
    --cc=git@vger$(echo .)kernel.org \
    --cc=gitster@pobox$(echo .)com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox