Junio C Hamano <gitster@xxxxxxxxx> 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.
