Re: [PATCH v2 1/2] pretty: add X-Change-ID to mail formats

>
> On Sun, 6 Jul 2025 at 22:53, Junio C Hamano <gitster@pobox.com> wrote:
> >
> > Junio C Hamano <gitster@pobox.com> writes:
> >
> > >> IMO the right way forward is to use a mail header.
> > >
> > > No.  In the change-id case, trailer is the right way to go.
> > > ...
> > > But after thinking thrice, we may find a set of good pieces of
> > > information that should be added as new commit header ...
> > > ... and there will be times when we need
> > > to convey them over e-mailed workflow to allow patch recipient not
> > > to lose such information.
> >
> > Or a third-party software may add a new commit header without
> > gauging and waiting for the community consensus anyway, which may or
> > may not have much structural meaning, and then we may want to extract
> > that piece of information hidden in the commit header out, because
> > it was not written as trailer (in which case there wouldn't have
> > needed any extra effort to extract it in the first place).
> >
> > This part can use a bit of clarification.
> >
> > My endorsement below to use an extra e-mail header applies when some
> > commit objects ended up with extra non-standard headers holding
> > pieces of information that we want to send as part of a patch,
> > whether it is a good idea or a bad idea to place that particular
> > kind of information in a commit header.  And the question is "Now,
> > what is the best way to transfer it over a patched e-mail?"
> >
> > If it were a good idea to place that particular kind of information
> > in a header, that is of course an effort worth investing in.
> >
> > If it were a horrible idea to place it in a header, it still is
> > worth investing in an effort to give ourselves a way to salvage such
> > information out of the header, even though we wouldn't have needed
> > such extra tool if they didn't hide it in the header.
>
> +1
>
> Does this also apply to commit signatures? I just created a signed
> commit and checked what `git format-patch` produces. I was a bit
> surprised to see that it doesn't seem to show up anywhere. Is it not
> supported or did I miss some flag or config?

>
> >
> > But once a generic mechanism is written, then Git does not have to
> > behave differently if an extra commit header is something a more
> > recent versions of Git tools started using after the idea gained
> > community consensus, or a third-party software unilaterally added
> > without gauging or waiting for community consensus.  The same single
> > mechanism can be used to extract the information and carry it in
> > e-mails, and mailinfo can be told to extract it out.  It can be left
> > up to the consumer after mailinfo disects the pieces of information
> > out of the e-mail.
> >
> > > In such a case, I fully agree that embedding in an e-mail header
> > > would be the way to go.
>
>
> Is it another option to put it somewhere in the body? Could we fit
> additional headers (e.g. signatures and third-party ones) somewhere
> between the `---` line and the additional diff? Or how about after the
> final `--` line? I haven't checked the specification. I just saw these
> lines in the `git format-patch` output.
>
> > >
> > > I would suggest a lot more generic implementation to solve it once
> > > and for all.  How about doing it more like this:
> > >
> > >    "git format-patch --extra-headers" grabs all extra headers
> > >    (i.e. those that are not the bog-standard "tree", "parent",
> > >    "author", "committer") and emit these
> > >
> > >     X-git-extra-commit-header: encoding=iso8859-1
> > >     X-git-extra-commit-header: frotz=nitfol
> > >
> > >    next to "Subject:", etc.