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

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