From: Johannes Sixt <j.sixt@viscovery.net>
Date: Fri, 18 Jan 2008 10:01:56 GMT
Subject: Re: [PATCH] git-send-email.perl: check for lines longer than 998 characters
Message-ID: <47907914.6000105@viscovery.net>
In-Reply-To: <4790746D.1000502@users.sourceforge.net>

Adam Piatyszek schrieb:
> * 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?

> 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.

You are right here. My thought was that even though the recipient gets a
broken patch, he would be able to fix it up. This may be acceptable for
peer-to-peer communication, but not for a development style that involves
many recipients.

Then git-format-patch and log-family with --pretty=email -p could warn
about these candidates-to-be-broken patches.

-- Hannes