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

[Junio C Hamano <gitster@pobox.com>]

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.

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.
>
> 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.