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@xxxxxxxxxxxxxxxxxxxxx .:................................:.
-
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
