[PATCH 0/3] Automatic transfer encoding for patches

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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(-)




[Index of Archives]     [Linux Kernel Development]     [Gcc Help]     [IETF Annouce]     [DCCP]     [Netdev]     [Networking]     [Security]     [V4L]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux SCSI]     [Fedora Users]

  Powered by Linux