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

Junio C Hamano <gitster@pobox.com> writes:

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.