Hi,
Jeff King <peff@xxxxxxxx> 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@xxxxxxxxxxxxxxxxxxxxx>
* 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@xxxxxxxxxxxxxxxxxxxxx .:................................:.
-
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
