git send-email has the --validate option, which is the default, to check if a patch has lines longer than RFC 5321 allows (998 octets). However, it doesn't take into account the fact that using certain transfer encodings makes this issue moot, and it also doesn't provide any helpful clue to the user about what to do when this fails.
This series introduces an "auto" value for --transfer-encoding that uses 8bit when possible (i.e. when lines are 998 octets or shorter) and quoted-printable otherwise; it then makes this the default behavior. It also makes --validate aware of transfer encoding so it doesn't complain when using quoted-printable or base64. git am already understands how to handle patches in any valid transfer encoding. As a result of this series, we always produce MIME messages with a Content-Transfer-Encoding header. I don't think this will cause any problems, but if someone knows of a reason why it would, please shout loudly. brian m. carlson (3): send-email: add an auto option for transfer encoding send-email: accept long lines with suitable transfer encoding send-email: automatically determine transfer-encoding Documentation/git-send-email.txt | 15 +++++---- git-send-email.perl | 36 ++++++++++---------- t/t9001-send-email.sh | 58 ++++++++++++++++++++++++++++++++ 3 files changed, 85 insertions(+), 24 deletions(-)
