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.
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).
Probably there should be a
4/3: send-email: add --encoding parameter
but I am not inclined to code it, especially this late in the release
freeze (though I think the first three are reasonable for v1.5.4, I am
also fine if you want to put them off -- I don't see this as a common
problem).
-Peff
-
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
