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

From: Adam Piatyszek <ediap@users.sourceforge.net>
Date: Jan 20, 2008, 22:35 UTC
Message-ID: <4793CCA2.4060407@users.sourceforge.net>
In-Reply-To: <7v8x2mdf7e.fsf@gitster.siamese.dyndns.org>

Hi,

Show 22 quoted lines

> 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]:

Show 6 quoted lines

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