[adding git list] On 9/5/19 7:25 AM, Christian Schoenebeck wrote: >>>>> How are you sending patches ? With git send-email ? If so, maybe you >>>>> can >>>>> pass something like --from='"Christian Schoenebeck" >>>>> '. Since this is a different string, git will >>>>> assume you're sending someone else's patch : it will automatically add >>>>> an >>>>> extra From: made out of the commit Author as recorded in the git tree. >>> >>> I think it is probably as simple as a 'git config' command to tell git >>> to always put a 'From:' in the body of self-authored patches when using >>> git format-patch; however, as I don't suffer from munged emails, I >>> haven't actually tested what that setting would be. > > Well, I tried that Eric. The expected solution would be enabling this git > setting: > > git config [--global] format.from true > https://git-scm.com/docs/git-config#Documentation/git-config.txt-formatfrom > > But as you can already read from the manual, the overall behaviour of git > regarding a separate "From:" line in the email body was intended solely for > the use case sender != author. So in practice (at least in my git version) git > always makes a raw string comparison between sender (name and email) string > and author string and only adds the separate From: line to the body if they > differ. > > Hence also "git format-patch --from=" only works here if you use a different > author string (name and email) there, otherwise on a perfect string match it > is simply ignored and you end up with only one "From:" in the email header. git folks: How hard would it be to improve 'git format-patch'/'git send-email' to have an option to ALWAYS output a From: line in the body, even when the sender is the author, for the case of a mailing list that munges the mail headers due to DMARC/DKIM reasons? > > So eventually I added one extra character in my name for now and removed it > manually in the dumped emails subsequently (see today's > "[PATCH v7 0/3] 9p: Fix file ID collisions"). > > Besides that direct string comparison restriction; git also seems to have a > bug here. Because even if you have sender != author, then git falsely uses > author as sender of the cover letter, whereas the emails of the individual > patches are encoded correctly. At any rate, I'm glad that you have figured out a workaround, even if painful, while we wait for git to provide what we really need. -- Eric Blake, Principal Software Engineer Red Hat, Inc. +1-919-301-3226 Virtualization: qemu.org | libvirt.org