[PATCH] git-send-email: provide hook to send lines more than 998 symbols

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
variable in shell script. So, define environment variable
GIT_SEND_EMAIL_LONGLINE to something to avoid that restriction.

Signed-off-by: Andy Shevchenko <redacted>
---
 git-send-email.perl |    2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)

diff --git a/git-send-email.perl b/git-send-email.perl
index 94ca5c8..29f700d 100755
--- a/git-send-email.perl
+++ b/git-send-email.perl

@@ -981,7 +981,7 @@ sub validate_patch {
 	open(my $fh, '<', $fn)
 		or die "unable to open $fn: $!\n";
 	while (my $line = <$fh>) {
-		if (length($line) > 998) {
+		if (length($line) > 998 and not $ENV{GIT_SEND_EMAIL_LONGLINE}) {
 			return "$.: patch contains a line longer than 998 characters";
 		}
 	}

-- 
1.6.0.2.GIT

On Fri, Nov 21, 2008 at 12:34 PM, Arafangion [off-list ref] wrote:

quoted

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
variable in shell script. So, define environment variable
GIT_SEND_EMAIL_LONGLINE to something to avoid that restriction.

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)

-- 
With Best Regards,
Andy Shevchenko

On Fri, 2008-11-21 at 12:37 +0200, Andy Shevchenko wrote:

On Fri, Nov 21, 2008 at 12:34 PM, Arafangion [off-list ref] wrote:

quoted

quoted

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>

quoted

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!)

Arafangion wrote:

On Fri, 2008-11-21 at 12:37 +0200, Andy Shevchenko wrote:

quoted

On Fri, Nov 21, 2008 at 12:34 PM, Arafangion [off-list ref] wrote:

quoted

quoted

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>

quoted

quoted

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@op5.se
OP5 AB                             www.op5.se
Tel: +46 8-230225                  Fax: +46 8-230231

On Fri, Nov 21, 2008 at 11:59:24AM +0200, Andy Shevchenko 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
variable in shell script. So, define environment variable
GIT_SEND_EMAIL_LONGLINE to something to avoid that restriction.

This already exists as "git send-email --no-validate", which
unfortunately doesn't seem to be documented. Care to send in a
documentation patch instead?

-Peff

On Fri, Nov 21, 2008 at 12:37:08PM +0200, Andy Shevchenko wrote:

quoted

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 am the author, and it was a direct response to a user who had
something in his mail path munging overly long lines (which are, in
fact, disallowed by rfc 2822).

Read this thread:

  http://thread.gmane.org/gmane.comp.version-control.git/70847

which contains the problem report and the patches. We could take this
one step further (but didn't at the time) by QP-encoding the body part
with long lines, which is what a normal MUA would do. Since the
receiving tools for git handle this situation, it should work fine. I
think such a patch would be welcome.

-Peff

Jeff King venit, vidit, dixit 21.11.2008 12:58:

On Fri, Nov 21, 2008 at 11:59:24AM +0200, Andy Shevchenko wrote:

quoted

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
variable in shell script. So, define environment variable
GIT_SEND_EMAIL_LONGLINE to something to avoid that restriction.

This already exists as "git send-email --no-validate", which
unfortunately doesn't seem to be documented. Care to send in a
documentation patch instead?

In fact it is documented in git-send-email.txt:

--[no-]validate::
        Perform sanity checks on patches.
        Currently, validation means the following:
+
--
                *       Warn of patches that contain lines longer than
998 characters; this
                        is due to SMTP limits as described by
http://www.ietf.org/rfc/rfc2821.txt.
--
+
Default is the value of 'sendemail.validate'; if this is not set,
default to '--validate'.


Cheers,
Michael

On Fri, 2008-11-21 at 11:59 +0200, Andy Shevchenko 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
variable in shell script. So, define environment variable
GIT_SEND_EMAIL_LONGLINE to something to avoid that restriction.

As a curiosity, why is such a check even neccessary?

On Fri, Nov 21, 2008 at 2:49 PM, Michael J Gruber
[off-list ref] wrote:

In fact it is documented in git-send-email.txt:
--[no-]validate::

That is I found just after I have sent the first email.

P.S. Thanks for all, patch is wrong.

-- 
With Best Regards,
Andy Shevchenko

On Fri, Nov 21, 2008 at 01:49:18PM +0100, Michael J Gruber wrote:

In fact it is documented in git-send-email.txt:

--[no-]validate::
        Perform sanity checks on patches.
        Currently, validation means the following:

Oh, right. Sorry, I stupidly looked at an older installed manpage
instead of going right to the source. So yes, it is documented.

-Peff