On Sun, 6 Jul 2025 at 22:53, Junio C Hamano <gitster@xxxxxxxxx> wrote: > > 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. +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.
