Arafangion wrote:
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
Well, there's quite a lot of arguing following that mail, and it
doesn't seem to end with a final decision.
I would be inclined to suggest that such patches should be sent as an
attachment instead?
No, that would be bad. Many communities (git included) discard
patches that aren't sent inline unless that's for a very good reason
(translation patches are almost always inline, as they tend to break
stuff for people who lack the proper encoding).
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.
Reviewable source-code doesn't contain lines longer than 100 or so lines
anyway, so we might as well break on some arbitrary (say, 200) width
and ask the user to resubmit with the "--attach" option if they really
want to send their patch.
--
Andreas Ericsson andreas.ericsson@xxxxxx
OP5 AB www.op5.se
Tel: +46 8-230225 Fax: +46 8-230231
--
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
