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

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

Hi,

> Jeff King <peff@peff.net> writes:
>> I think that is sensible. Patch series will follow:
>>
>>   1/3: send-email: detect invocation errors earlier
>>
>>        This is a code cleanup in preparation for 2/3, but has
>>        user-friendly side effects.
>>
>>   2/3: send-email: validate patches before sending anything
>>
>>        The actual up front long-lines check.
> 
> I wonder what the performance implication of this approach would
> be, though.  I am tempted to say that it would be negligible --
> scanning text in Perl is fast enough.
> 
>>   3/3: send-email: add no-validate option
>>
>>        A knob for users who know something send-email doesn't.
>>
>> That at least detects the situation and lets the user deal with it (by
>> fixing the patch, or by sending it as an attachment with another MUA).

Thanks Peff for your patches. I was about to implement your first two, 
but it would take me much more time to do it in a sane way. ;-)

So:

Acked-by: Adam Piątyszek <ediap@users.sourceforge.net>

* Junio C Hamano [18 I 2008 21:57]:
> I suspect that taking this "Safe against SMTP line length limit"
> topic all the way ("all the way" is post 1.5.4, I am inclined to
> agree that this may be a good fix to an existing bug) would
> require that git-format-patch --attach to learn to apply QP on
> patch text to avoid producing very long lines to root-cause the
> issue [*1*].

I support this idea. "git-format-patch --attach" is a good place to 
implement such an additional encoding. Of course, git-mailinfo needs to 
be extended with a decoding method as well.

> [Footnote]
> 
> *1* It's actually second-to-root-cause it, because the real root
> cause is for the source tree to have such an insanely long line.

I can not fully agree with this statement. You should have in mind that 
git is by the definition a "stupid content tracker" and should not 
assume any particular kind of data being processed.
For instance, the reported problem with git-send-email was discovered 
when I tried to send a patch with some reference data of an unformatted 
standard output of a test program.

BR,
/Adam

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