Jeff King <peff@xxxxxxxx> writes:
> 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.
> 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@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
