Jeff King <peff@peff.net> writes:

quoted text
> On Fri, Jan 18, 2008 at 02:08:24AM -0800, Junio C Hamano wrote:
>
>> On the other hand, git-send-email _is_ all about SMTP transfer.
>> Perhaps a loop over input files upfront to check the line length
>> limit, and warn if there are suspiciously long lines even before
>> sending the first piece of e-mail out, would be a reasonable
>> approach.
>
> 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.

quoted text
>   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).

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

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