git.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Eric Sunshine <sunshine@sunshineco.com>
To: "brian m. carlson" <sandals@crustytoothpaste.net>
Cc: Git List <git@vger.kernel.org>,
	Jonathan Tan <jonathantanmy@google.com>,
	Junio C Hamano <gitster@pobox.com>,
	sir@cmpwn.com
Subject: Re: [PATCH 2/3] send-email: accept long lines with suitable transfer encoding
Date: Fri, 6 Jul 2018 02:08:17 -0400	[thread overview]
Message-ID: <CAPig+cTNGNCUxoBdunAvjAKy5w_oYaLJ7HiAp1vYCtPmDEOUww@mail.gmail.com> (raw)
In-Reply-To: <20180706022357.739657-3-sandals@crustytoothpaste.net>

On Thu, Jul 5, 2018 at 10:24 PM brian m. carlson
<sandals@crustytoothpaste.net> wrote:
> With --validate (which is the default), we warn about lines exceeding
> 998 characters due to the limits specified in RFC 5321.  However, if
> we're using a suitable transfer encoding (quoted-printable or base64),
> we're guaranteed not to have lines exceeding 76 characters, so there's
> no need to fail in this case.  The auto transfer encoding handles this
> specific case, so accept it as well.
>
> Signed-off-by: brian m. carlson <sandals@crustytoothpaste.net>
> ---
> diff --git a/Documentation/git-send-email.txt b/Documentation/git-send-email.txt
> @@ -401,8 +401,9 @@ have been specified, in which case default to 'compose'.
> -               *       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.
> +               *       Warn of patches that contain lines longer than 998 characters unless
> +                       a suitable transfer encoding is used; this is due to SMTP limits as
> +                       described by http://www.ietf.org/rfc/rfc2821.txt.

A reader might like to know what "a suitable transfer encoding" is.
Perhaps add a "such as 'auto', 'quoted-printable' and 'base64'"
comment?

> diff --git a/t/t9001-send-email.sh b/t/t9001-send-email.sh
> @@ -480,6 +480,19 @@ test_expect_success $PREREQ 'long lines with auto encoding are quoted-printable'
> +test_expect_success $PREREQ '--validate passes with certain encodings' '
> +       for enc in auto quoted-printable base64
> +       do
> +               git send-email \
> +                       --from="Example <nobody@example.com>" \
> +                       --to=nobody@example.com \
> +                       --smtp-server="$(pwd)/fake.sendmail" \
> +                       --transfer-encoding=$enc \
> +                       --validate \
> +                       $patches longline.patch
> +       done
> +'

If you turn this inside out, it will be easier to figure out which
encoding fails (if one ever does). That is:

    for enc in auto quoted-printable base64
    do
        test_expect_success $PREREQ "--validate passes with encoding $enc" '
            git send-email ...
        '
    done

  reply	other threads:[~2018-07-06  6:10 UTC|newest]

Thread overview: 16+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-07-06  2:23 [PATCH 0/3] Automatic transfer encoding for patches brian m. carlson
2018-07-06  2:23 ` [PATCH 1/3] send-email: add an auto option for transfer encoding brian m. carlson
2018-07-06  6:01   ` Eric Sunshine
2018-07-06 20:19     ` brian m. carlson
2018-07-06  2:23 ` [PATCH 2/3] send-email: accept long lines with suitable " brian m. carlson
2018-07-06  6:08   ` Eric Sunshine [this message]
2018-07-06 12:26   ` Drew DeVault
2018-07-06 20:18     ` brian m. carlson
2018-07-06  2:23 ` [PATCH 3/3] send-email: automatically determine transfer-encoding brian m. carlson
2018-07-06 12:26 ` [PATCH 0/3] Automatic transfer encoding for patches Drew DeVault
2018-07-08 22:17 ` [PATCH v2 0/4] " brian m. carlson
2018-07-08 22:17   ` [PATCH v2 1/4] send-email: add an auto option for transfer encoding brian m. carlson
2018-07-08 22:17   ` [PATCH v2 2/4] send-email: accept long lines with suitable " brian m. carlson
2018-07-08 22:17   ` [PATCH v2 3/4] send-email: automatically determine transfer-encoding brian m. carlson
2018-07-08 22:17   ` [PATCH v2 4/4] docs: correct RFC specifying email line length brian m. carlson
2018-07-08 22:22   ` [PATCH v2 0/4] Automatic transfer encoding for patches Drew DeVault

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=CAPig+cTNGNCUxoBdunAvjAKy5w_oYaLJ7HiAp1vYCtPmDEOUww@mail.gmail.com \
    --to=sunshine@sunshineco.com \
    --cc=git@vger.kernel.org \
    --cc=gitster@pobox.com \
    --cc=jonathantanmy@google.com \
    --cc=sandals@crustytoothpaste.net \
    --cc=sir@cmpwn.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).