On Fri, 2008-11-21 at 12:37 +0200, Andy Shevchenko wrote: > On Fri, Nov 21, 2008 at 12:34 PM, Arafangion <thestar@xxxxxxxxxxxxxxxx> wrote: > >> By default git-send-email does not accept patch which is contain lines longer > >> than 998 symbols. Sometime it's inconvenient, i.e. you have a long list in one <snip> > > As a curiosity, why is such a check even neccessary? > I'm not an author of that strange check (possible it's somehow related > to b8ebe08b9a643f432866eb7150c3b20d59b755f2) I can't seem to find that changeset, however the reason why I asked is because I thought I remembered that some mail clients could crash if they got lines longer than that, and we should cater for that even if those clients should handle mails better than that! Apparently it's specified in the relevant RFC2822, and this particular solution has already been contributed as: https://kerneltrap.org/mailarchive/git/2008/1/18/579779 I would be inclined to suggest that such patches should be sent as an attachment instead? (Though this may become bikeshed painting on my part, see http://www.freebsd.org/doc/en/articles/mailing-list-faq/bikeshed.html for what I mean by the term). While patches should be sent inline to encourage discussion of the patch, if the patch has such insanely long lines, the probability that the bulk of your audience in having a good email client that doesn't mangle your patch may become rather low. (I really should get some sleep, not good to be argumentative when people are contributing very useful patches, like yourself!) -- 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
