On Tue, Jan 12 2021, Jonas Bernoulli wrote: > Tomi Ollila <tomi.ollila@iki.fi> writes: >> Note that messages >> >> 20210110140112.25930-11-jonas@bernoul.li and >> 20210110140112.25930-12-jonas@bernoul.li >> >> have base64 -encoded content, with CRLF line endings >> so those don't apply as is, but CR's from the encoded >> content must be deleted. > > Do you know why git would decide to send these commits that way? I do know: In my case: - git format-patch ... - in one of the patch files there are utf-8 characters - git send-email (to mailing list and to tomi.ollila@iki.fi) - first stop in email is in smtp.iki.fi (which I use to send email) - the email that returns directly from iki.fi does not have base64 encoded content *nor* CR's in email body - the mail that is sent to notmuchmail.org, will contain CRLF line endings; either smtp.iki.fi adds those or notmuchmail.org smtpd added those - the mailman in notmuchmail.org notices that there is 8bit content in email body, and decides to base64-encode the whole content with CRLF line endings. - git am, the --no-keep-cr option (default) if not effective in "embedded" base64-encoded content. That particular feature is just for that purpose that smtp content should have CRLF line endings and the files those patches refer to often don't have (--keep-cr can be used if CRLF file endings are expected). It is a "feature" that in base64-encoded content is handled as verbatim by git-am, git-apply and so on. For reference: the email https://www.mail-archive.com/notmuch@notmuchmail.org/msg50113.html got directly (via-iki-smtpd) and via mailing list (via-notmuch-mailman) has the following headers (among other headers) in my mail storage (and as said above, the one got directly did not have CRLF line endings) $ grep Content via-iki-smtpd via-notmuch-mailman via-iki-smtpd:Content-Type: text/plain; charset=UTF-8 via-iki-smtpd:Content-Transfer-Encoding: 8bit via-notmuch-mailman:Content-Type: text/plain; charset="utf-8" via-notmuch-mailman:Content-Transfer-Encoding: base64 > Maybe we should try to keep it from doing that? I didn't write > down the prompt but git actually asked something along the line > of "for these two messages you have to select the base64 encoding, > does utf-8 work for you?". Right, the base64 encoding can be used when using git send-email, but how many knows to do that :) (Tried to look what option is it, but man git-send-email gave me manpage of version 1.7.1 >;/). Other options: - modify mailman (David Bremner contacted mailman mailing list, they don't think that is a bug (well IMO is it not a bug, but...) anyway one could hack locally ;/ (or the smtpd frontend if there is any) - modify git-am (based on Julio Hamano's comment on some mailing list something like if there is clear and sound implementation -- was it some filter option then something could get in... (or something)) - based on irclogs (2020-08) David has tool to be offered to (debian)-mailscripts to filter CR's out from base64-encoded content. -- which I think is better place as this problem isn't notmuch specific (although having such a tool in devel/ would be more convenient for me) > > Jonas Tomi _______________________________________________ notmuch mailing list -- notmuch@notmuchmail.org To unsubscribe send an email to notmuch-leave@notmuchmail.org