Re: [PATCH] git-send-email.perl: check for lines longer than 998 characters

[Adam Piatyszek <ediap@users.sourceforge.net>]

Hi,

* Johannes Sixt [18 I 2008 09:12]:
> Is it good to die() in this situation? If you are sending a patch series
> and one patch in the middle triggers this condition, then only half of the
> series is sent. Maybe it would be better to warn here only, collect file
> names of the suspects, send the patch nevertheless, and write a summary at
> the end?

Unfortunately, my experience in perl programming is very, very limited. 
So, I did not prepared the final solution for this problem. ;-) The 
patch was intended as a startup of a discussion how to fix this issue.

IMHO it does not make much sense to send such patches nevertheless, if 
we are sure that they will be broken after SMTP transfer. Such a 
situation is similar to spamming. And sending only the ones that can be 
sent is not an option as well.

The proper solution would be to implement conditional encoding of such 
patches, e.g. quoted-printable as suggested by Peff, and warn users that 
some patches were send as encoded. Also an explicit option 
"--transfer-enc" might be added to control such a behaviour manually.

I guess, git send-email might reuse the code from this perl module:
http://search.cpan.org/src/GAAS/MIME-Base64-Perl-1.00/lib/MIME/QuotedPrint/Perl.pm
to implement the encoding routine.

There are although two things to implement:
1) When too long line is detected, the whole message body has to be 
encoded with QP.
2) Proper "Content-Transfer-Encoding: quoted-printable" needs to be set 
in the headers.

BTW, is "git am" or "git apply" able to decode the QP encoded message 
body? I guess yes, since it works with patches attached to emails as well...

Comments?

BR,
/Adam


-- 
.:.  Adam Piatyszek (ediap)  .:.....................................:.
.:.  ediap@users.sourceforge.net  .:................................:.