Re: [PATCH 2/2] send-email: supply a --send-delay=1 by default

[Eric Wong]

Ævar Arnfjörð Bjarmason  wrote:
> Good point. I also see that (via git log --author=Ævar --grep='^\[PATCH
> ') that this series itself arrived out of order (0 -> 2 -> 1), but I
> don't know to what extent public-inbox itself might be batching things.

public-inbox doesn't batch, aside from when the
public-inbox-watch process gets restarted and needs to catch up
using readdir.  Once it's done catching up with readdir, it
gets into an inotify loop which injects messages in the order
the MTA (or offlineimap) puts them in a Maildir.

Right now, public-inbox only sorts by Date: header in the mail.

The next Xapian schema revision of public-inbox will use
internally sorts search results(*) by the date in the newest
Received: header.  That is analogous to git committer date.  The
displayed message date will still be sorted by the Date: header
(analogous to git author date); since git-send-email already
alters the Date: in a series for sorting.

This allow messages/threads which are actually new get bumped to
the top of the homepage; regardless of how wrong the original
sender's clock was.

It should help prevent kernel developers from crafting message
dates with optimization for classic^Wextra reviews in mind :)


(*) all the look-at-a-bunch-of-messages operations, including
the landing page (e.g. https://public-inbox.org/git/)
is a Xapian search query, nowadays; but "git log"

Re: [PATCH 2/2] send-email: supply a --send-delay=1 by default

[Eric Wong]

Ævar Arnfjörð Bjarmason  wrote:
> Good point. I also see that (via git log --author=Ævar --grep='^\[PATCH
> ') that this series itself arrived out of order (0 -> 2 -> 1), but I
> don't know to what extent public-inbox itself might be batching things.

public-inbox doesn't batch, aside from when the
public-inbox-watch process gets restarted and needs to catch up
using readdir.  Once it's done catching up with readdir, it
gets into an inotify loop which injects messages in the order
the MTA (or offlineimap) puts them in a Maildir.

Right now, public-inbox only sorts by Date: header in the mail.

The next Xapian schema revision of public-inbox will use
internally sorts search results(*) by the date in the newest
Received: header.  That is analogous to git committer date.  The
displayed message date will still be sorted by the Date: header
(analogous to git author date); since git-send-email already
alters the Date: in a series for sorting.

This allow messages/threads which are actually new get bumped to
the top of the homepage; regardless of how wrong the original
sender's clock was.

It should help prevent kernel developers from crafting message
dates with optimization for classic^Wextra reviews in mind :)


(*) all the look-at-a-bunch-of-messages operations, including
the landing page (e.g. https://public-inbox.org/git/)
is a Xapian search query, nowadays; but "git log"

Re: [PATCH 2/2] send-email: supply a --send-delay=1 by default

[Junio C Hamano]

Eric Sunshine  writes:

> A minor point: Are you sure that it's git-format-patch that's being
> careful about arranging Date: to display in the desired order, and not
> git-send-email? Looking at old patches I still have hanging around
> which were created with git-format-patch, I see the Date: headers are
> wildly out of order, presumably because the date is taken from
> Author-Date: and the patches were heavily rebased.

send-email uses the current time as the timestamp it lets MTA to see
(and for a N-patch series, the first patch gets current time minus
N, and later patches get newer timestamps with 1 second increment).

The Date: field in the input file to the command has nothing to
participate in this process; sending a series that has patches that
have been shuffled with "rebase -i" would still give older timestamp
to the earlier message while sending the series out.

That is sufficient for any MUA that is capable of sorting the
messages in the sender's timestamp order; even though there is no
way to force the actual order in which an MTA on the receiving end
sees the messages, it is not necessary and it would not help X-<.

Re: [PATCH 2/2] send-email: supply a --send-delay=1 by default

[Junio C Hamano]

Eric Sunshine  writes:

> A minor point: Are you sure that it's git-format-patch that's being
> careful about arranging Date: to display in the desired order, and not
> git-send-email? Looking at old patches I still have hanging around
> which were created with git-format-patch, I see the Date: headers are
> wildly out of order, presumably because the date is taken from
> Author-Date: and the patches were heavily rebased.

send-email uses the current time as the timestamp it lets MTA to see
(and for a N-patch series, the first patch gets current time minus
N, and later patches get newer timestamps with 1 second increment).

The Date: field in the input file to the command has nothing to
participate in this process; sending a series that has patches that
have been shuffled with "rebase -i" would still give older timestamp
to the earlier message while sending the series out.

That is sufficient for any MUA that is capable of sorting the
messages in the sender's timestamp order; even though there is no
way to force the actual order in which an MTA on the receiving end
sees the messages, it is not necessary and it would not help X-<.

Re: [PATCH 2/2] send-email: supply a --send-delay=1 by default

[Junio C Hamano]

"brian m. carlson"  writes:

> I'm not sure that this is going to have the effect you want it to have.
> Let me give an example to demonstrate why.
> ...
> In short, I don't think this is going to be especially helpful because
> it won't change the status quo for a lot of senders.  You'd have to
> insert some significant delay in order to get the effect you desire, and
> even then things could still be delivered out of order.

Thanks for explaining it clearly.

In the past on this list those who do not get the store-and-forward
nature of e-mail transport have brought this up a few times, but
this approach fundamentally do not work, at least for the purpose of
forcing ordering of messages at the receiving end.

Re: [PATCH 2/2] send-email: supply a --send-delay=1 by default

[Junio C Hamano]

"brian m. carlson"  writes:

> I'm not sure that this is going to have the effect you want it to have.
> Let me give an example to demonstrate why.
> ...
> In short, I don't think this is going to be especially helpful because
> it won't change the status quo for a lot of senders.  You'd have to
> insert some significant delay in order to get the effect you desire, and
> even then things could still be delivered out of order.

Thanks for explaining it clearly.

In the past on this list those who do not get the store-and-forward
nature of e-mail transport have brought this up a few times, but
this approach fundamentally do not work, at least for the purpose of
forcing ordering of messages at the receiving end.

Re: [PATCH 2/2] send-email: supply a --send-delay=1 by default

[Eric Sunshine]

On Sun, Mar 25, 2018 at 2:28 PM, Ævar Arnfjörð Bjarmason
 wrote:
> The earlier change to add this option described the problem this
> option is trying to solve.
>
> This turns it on by default with a value of 1 second, which'll
> hopefully solve it, and if not user reports as well as the
> X-Mailer-Send-Delay header should help debug it.
> [...]
> Signed-off-by: Ævar Arnfjörð Bjarmason 
> ---
> diff --git a/Documentation/config.txt b/Documentation/config.txt
> @@ -3070,7 +3070,18 @@ sendemail.smtpReloginDelay::
>  sendemail.smtpSendDelay::
> Seconds wait in between message sending before sending another
> -   message. Set it to 0 to impose no extra delay, defaults to 0.
> +   message. Set it to 0 to impose no extra delay, defaults to 1
> +   to wait 1 second.
> ++
> +The reason for imposing a default delay is because certain popular
> +E-Mail clients such as Google's GMail completely ignore the "Date"
> +header, which format-patch is careful to set such that the patches
> +will be displayed in order, and instead sort by the time the E-mail
> +was received.

A minor point: Are you sure that it's git-format-patch that's being
careful about arranging Date: to display in the desired order, and not
git-send-email? Looking at old patches I still have hanging around
which were created with git-format-patch, I see the Date: headers are
wildly out of order, presumably because the date is taken from
Author-Date: and the patches were heavily rebased.

Re: [PATCH 2/2] send-email: supply a --send-delay=1 by default

[Eric Sunshine]

On Sun, Mar 25, 2018 at 2:28 PM, Ævar Arnfjörð Bjarmason
 wrote:
> The earlier change to add this option described the problem this
> option is trying to solve.
>
> This turns it on by default with a value of 1 second, which'll
> hopefully solve it, and if not user reports as well as the
> X-Mailer-Send-Delay header should help debug it.
> [...]
> Signed-off-by: Ævar Arnfjörð Bjarmason 
> ---
> diff --git a/Documentation/config.txt b/Documentation/config.txt
> @@ -3070,7 +3070,18 @@ sendemail.smtpReloginDelay::
>  sendemail.smtpSendDelay::
> Seconds wait in between message sending before sending another
> -   message. Set it to 0 to impose no extra delay, defaults to 0.
> +   message. Set it to 0 to impose no extra delay, defaults to 1
> +   to wait 1 second.
> ++
> +The reason for imposing a default delay is because certain popular
> +E-Mail clients such as Google's GMail completely ignore the "Date"
> +header, which format-patch is careful to set such that the patches
> +will be displayed in order, and instead sort by the time the E-mail
> +was received.

A minor point: Are you sure that it's git-format-patch that's being
careful about arranging Date: to display in the desired order, and not
git-send-email? Looking at old patches I still have hanging around
which were created with git-format-patch, I see the Date: headers are
wildly out of order, presumably because the date is taken from
Author-Date: and the patches were heavily rebased.

Re: [PATCH 2/2] send-email: supply a --send-delay=1 by default

[Ævar Arnfjörð Bjarmason]

On Sun, Mar 25 2018, brian m. carlson wrote:

> On Sun, Mar 25, 2018 at 06:28:03PM +, Ævar Arnfjörð Bjarmason wrote:
>> The earlier change to add this option described the problem this
>> option is trying to solve.
>>
>> This turns it on by default with a value of 1 second, which'll
>> hopefully solve it, and if not user reports as well as the
>> X-Mailer-Send-Delay header should help debug it.
>>
>> I think the trade-off of slowing down E-Mail sending to turn this on
>> makes sense because:
>>
>>  * GMail is a really common client, git.git's own unique authors by
>>%aE are ~30% @gmail.com, ~20% for linux.git. That's just patch
>>submitters, my guess is this it's much more common among those who
>>mostly read the list, and those users who aren't using mu4e / mutt
>>etc. anyway.
>>
>>  * There's really no point in having this feature at all if it's not
>>made the default, since the entire point is to be able to read a
>>list like the git ML or the LKML and have patches from others show
>>up in order.
>>
>>  * I don't think anyone's really sensitive to the sending part of
>>send-email taking longer. You just choose "all" and then switch to
>>another terminal while it does its thing if you have a huge series,
>>and for 1-3 patches I doubt anyone would notice this anyway.
>
> I'm not sure that this is going to have the effect you want it to have.
> Let me give an example to demonstrate why.
>
> If I send a series to the list, in order for this to work, you need my
> SMTP server (Postfix) to essentially send mails slowly enough to
> vger.kernel.org (ZMailer) that it doesn't batch them when it sends them
> to GMail.  The problem is that with my mail server, due to filtering and
> such, already takes at least a second to accept, process, and relay
> submitted messages.  vger still batched them and delivered them back to
> me out of order.  This will be even worse with large series.
>
> You are also assuming that my mail server will not have batched them and
> delivered them out of order, which it might well do, since Postfix uses
> a connection cache to machines that don't do STARTTLS (which, much to my
> annoyance, vger doesn't offer).
>
> In short, I don't think this is going to be especially helpful because
> it won't change the status quo for a lot of senders.  You'd have to
> insert some significant delay in order to get the effect you desire, and
> even then things could still be delivered out of order.

Good point. I also see that (via git log --author=Ævar --grep='^\[PATCH
') that this series itself arrived out of order (0 -> 2 -> 1), but I
don't know to what extent public-inbox itself might be batching things.

It would be interesting to get reports from other GMail users as to what
order these mails were shown in, but I think as soon as they're replied
to that info's gone, at least for 2/2, which is the potentially out of
order one in this case.

In general I realize that this won't be a general solution that'll work
in all cases. E.g. I have a local SMTP on my laptop, if I'm on a plane
it wouldn't matter if the delay was 2 hours, it would be batched up
locally and sent all at once.

I was hoping we could find some sweet spot where the systems along the
way (common smtpd's, majordomo, public-inbox's git repo) would as a
result get this right most of the time for the purposes of appeasing
this really common mail client, but maybe that's not going to work out.

Re: [PATCH 2/2] send-email: supply a --send-delay=1 by default

[Ævar Arnfjörð Bjarmason]

On Sun, Mar 25 2018, brian m. carlson wrote:

> On Sun, Mar 25, 2018 at 06:28:03PM +, Ævar Arnfjörð Bjarmason wrote:
>> The earlier change to add this option described the problem this
>> option is trying to solve.
>>
>> This turns it on by default with a value of 1 second, which'll
>> hopefully solve it, and if not user reports as well as the
>> X-Mailer-Send-Delay header should help debug it.
>>
>> I think the trade-off of slowing down E-Mail sending to turn this on
>> makes sense because:
>>
>>  * GMail is a really common client, git.git's own unique authors by
>>%aE are ~30% @gmail.com, ~20% for linux.git. That's just patch
>>submitters, my guess is this it's much more common among those who
>>mostly read the list, and those users who aren't using mu4e / mutt
>>etc. anyway.
>>
>>  * There's really no point in having this feature at all if it's not
>>made the default, since the entire point is to be able to read a
>>list like the git ML or the LKML and have patches from others show
>>up in order.
>>
>>  * I don't think anyone's really sensitive to the sending part of
>>send-email taking longer. You just choose "all" and then switch to
>>another terminal while it does its thing if you have a huge series,
>>and for 1-3 patches I doubt anyone would notice this anyway.
>
> I'm not sure that this is going to have the effect you want it to have.
> Let me give an example to demonstrate why.
>
> If I send a series to the list, in order for this to work, you need my
> SMTP server (Postfix) to essentially send mails slowly enough to
> vger.kernel.org (ZMailer) that it doesn't batch them when it sends them
> to GMail.  The problem is that with my mail server, due to filtering and
> such, already takes at least a second to accept, process, and relay
> submitted messages.  vger still batched them and delivered them back to
> me out of order.  This will be even worse with large series.
>
> You are also assuming that my mail server will not have batched them and
> delivered them out of order, which it might well do, since Postfix uses
> a connection cache to machines that don't do STARTTLS (which, much to my
> annoyance, vger doesn't offer).
>
> In short, I don't think this is going to be especially helpful because
> it won't change the status quo for a lot of senders.  You'd have to
> insert some significant delay in order to get the effect you desire, and
> even then things could still be delivered out of order.

Good point. I also see that (via git log --author=Ævar --grep='^\[PATCH
') that this series itself arrived out of order (0 -> 2 -> 1), but I
don't know to what extent public-inbox itself might be batching things.

It would be interesting to get reports from other GMail users as to what
order these mails were shown in, but I think as soon as they're replied
to that info's gone, at least for 2/2, which is the potentially out of
order one in this case.

In general I realize that this won't be a general solution that'll work
in all cases. E.g. I have a local SMTP on my laptop, if I'm on a plane
it wouldn't matter if the delay was 2 hours, it would be batched up
locally and sent all at once.

I was hoping we could find some sweet spot where the systems along the
way (common smtpd's, majordomo, public-inbox's git repo) would as a
result get this right most of the time for the purposes of appeasing
this really common mail client, but maybe that's not going to work out.

Re: [PATCH 2/2] send-email: supply a --send-delay=1 by default

[brian m. carlson]

On Sun, Mar 25, 2018 at 06:28:03PM +, Ævar Arnfjörð Bjarmason wrote:
> The earlier change to add this option described the problem this
> option is trying to solve.
> 
> This turns it on by default with a value of 1 second, which'll
> hopefully solve it, and if not user reports as well as the
> X-Mailer-Send-Delay header should help debug it.
> 
> I think the trade-off of slowing down E-Mail sending to turn this on
> makes sense because:
> 
>  * GMail is a really common client, git.git's own unique authors by
>%aE are ~30% @gmail.com, ~20% for linux.git. That's just patch
>submitters, my guess is this it's much more common among those who
>mostly read the list, and those users who aren't using mu4e / mutt
>etc. anyway.
> 
>  * There's really no point in having this feature at all if it's not
>made the default, since the entire point is to be able to read a
>list like the git ML or the LKML and have patches from others show
>up in order.
> 
>  * I don't think anyone's really sensitive to the sending part of
>send-email taking longer. You just choose "all" and then switch to
>another terminal while it does its thing if you have a huge series,
>and for 1-3 patches I doubt anyone would notice this anyway.

I'm not sure that this is going to have the effect you want it to have.
Let me give an example to demonstrate why.

If I send a series to the list, in order for this to work, you need my
SMTP server (Postfix) to essentially send mails slowly enough to
vger.kernel.org (ZMailer) that it doesn't batch them when it sends them
to GMail.  The problem is that with my mail server, due to filtering and
such, already takes at least a second to accept, process, and relay
submitted messages.  vger still batched them and delivered them back to
me out of order.  This will be even worse with large series.

You are also assuming that my mail server will not have batched them and
delivered them out of order, which it might well do, since Postfix uses
a connection cache to machines that don't do STARTTLS (which, much to my
annoyance, vger doesn't offer).

In short, I don't think this is going to be especially helpful because
it won't change the status quo for a lot of senders.  You'd have to
insert some significant delay in order to get the effect you desire, and
even then things could still be delivered out of order.
-- 
brian m. carlson / brian with sandals: Houston, Texas, US
https://www.crustytoothpaste.net/~bmc | My opinion only
OpenPGP: https://keybase.io/bk2204


signature.asc
Description: PGP signature

Re: [PATCH 2/2] send-email: supply a --send-delay=1 by default

[brian m. carlson]

On Sun, Mar 25, 2018 at 06:28:03PM +, Ævar Arnfjörð Bjarmason wrote:
> The earlier change to add this option described the problem this
> option is trying to solve.
> 
> This turns it on by default with a value of 1 second, which'll
> hopefully solve it, and if not user reports as well as the
> X-Mailer-Send-Delay header should help debug it.
> 
> I think the trade-off of slowing down E-Mail sending to turn this on
> makes sense because:
> 
>  * GMail is a really common client, git.git's own unique authors by
>%aE are ~30% @gmail.com, ~20% for linux.git. That's just patch
>submitters, my guess is this it's much more common among those who
>mostly read the list, and those users who aren't using mu4e / mutt
>etc. anyway.
> 
>  * There's really no point in having this feature at all if it's not
>made the default, since the entire point is to be able to read a
>list like the git ML or the LKML and have patches from others show
>up in order.
> 
>  * I don't think anyone's really sensitive to the sending part of
>send-email taking longer. You just choose "all" and then switch to
>another terminal while it does its thing if you have a huge series,
>and for 1-3 patches I doubt anyone would notice this anyway.

I'm not sure that this is going to have the effect you want it to have.
Let me give an example to demonstrate why.

If I send a series to the list, in order for this to work, you need my
SMTP server (Postfix) to essentially send mails slowly enough to
vger.kernel.org (ZMailer) that it doesn't batch them when it sends them
to GMail.  The problem is that with my mail server, due to filtering and
such, already takes at least a second to accept, process, and relay
submitted messages.  vger still batched them and delivered them back to
me out of order.  This will be even worse with large series.

You are also assuming that my mail server will not have batched them and
delivered them out of order, which it might well do, since Postfix uses
a connection cache to machines that don't do STARTTLS (which, much to my
annoyance, vger doesn't offer).

In short, I don't think this is going to be especially helpful because
it won't change the status quo for a lot of senders.  You'd have to
insert some significant delay in order to get the effect you desire, and
even then things could still be delivered out of order.
-- 
brian m. carlson / brian with sandals: Houston, Texas, US
https://www.crustytoothpaste.net/~bmc | My opinion only
OpenPGP: https://keybase.io/bk2204


signature.asc
Description: PGP signature

[PATCH 2/2] send-email: supply a --send-delay=1 by default

[Ævar Arnfjörð Bjarmason]

The earlier change to add this option described the problem this
option is trying to solve.

This turns it on by default with a value of 1 second, which'll
hopefully solve it, and if not user reports as well as the
X-Mailer-Send-Delay header should help debug it.

I think the trade-off of slowing down E-Mail sending to turn this on
makes sense because:

 * GMail is a really common client, git.git's own unique authors by
   %aE are ~30% @gmail.com, ~20% for linux.git. That's just patch
   submitters, my guess is this it's much more common among those who
   mostly read the list, and those users who aren't using mu4e / mutt
   etc. anyway.

 * There's really no point in having this feature at all if it's not
   made the default, since the entire point is to be able to read a
   list like the git ML or the LKML and have patches from others show
   up in order.

 * I don't think anyone's really sensitive to the sending part of
   send-email taking longer. You just choose "all" and then switch to
   another terminal while it does its thing if you have a huge series,
   and for 1-3 patches I doubt anyone would notice this anyway.

Signed-off-by: Ævar Arnfjörð Bjarmason 
---
 Documentation/config.txt | 13 -
 git-send-email.perl  |  1 +
 t/t9001-send-email.sh|  4 ++--
 3 files changed, 15 insertions(+), 3 deletions(-)

diff --git a/Documentation/config.txt b/Documentation/config.txt
index f155d349c0..bd578642c1 100644
--- a/Documentation/config.txt
+++ b/Documentation/config.txt
@@ -3070,7 +3070,18 @@ sendemail.smtpReloginDelay::
 
 sendemail.smtpSendDelay::
Seconds wait in between message sending before sending another
-   message. Set it to 0 to impose no extra delay, defaults to 0.
+   message. Set it to 0 to impose no extra delay, defaults to 1
+   to wait 1 second.
++
+The reason for imposing a default delay is because certain popular
+E-Mail clients such as Google's GMail completely ignore the "Date"
+header, which format-patch is careful to set such that the patches
+will be displayed in order, and instead sort by the time the E-mail
+was received.
++
+This causes sent E-Mail to be shown completely out of order in such
+clients, imposing the delay is a workaround that should usually work
+(although it's by no means guaranteed).
 +
 See also the `--send-delay` option of linkgit:git-send-email[1].
 
diff --git a/git-send-email.perl b/git-send-email.perl
index 013277ede2..ddbc44f1c9 100755
--- a/git-send-email.perl
+++ b/git-send-email.perl
@@ -489,6 +489,7 @@ die sprintf(__("Unknown --confirm setting: '%s'\n"), 
$confirm)
unless $confirm =~ /^(?:auto|cc|compose|always|never)/;
 die sprintf(__("Invalid --send-delay setting: '%s'\n"), $send_delay)
if defined $send_delay and $send_delay !~ /^[0-9]+$/s;
+$send_delay = 1 unless defined $send_delay;
 
 # Debugging, print out the suppressions.
 if (0) {
diff --git a/t/t9001-send-email.sh b/t/t9001-send-email.sh
index fafa61c5d6..1580e00fce 100755
--- a/t/t9001-send-email.sh
+++ b/t/t9001-send-email.sh
@@ -1713,7 +1713,7 @@ test_expect_success '--send-delay expects whole 
non-negative seconds' '
test_i18ngrep "Invalid --send-delay setting" errors
 '
 
-test_expect_success $PREREQ "there is no default --send-delay" '
+test_expect_success $PREREQ "there is a default --send-delay" '
clean_fake_sendmail &&
rm -fr outdir &&
git format-patch -3 -o outdir &&
@@ -1724,7 +1724,7 @@ test_expect_success $PREREQ "there is no default 
--send-delay" '
outdir/*.patch \
2>stderr >stdout &&
test $(grep -c "X-Mailer:" stdout) = 3 &&
-   test $(grep -c "X-Mailer-Send-Delay:" stdout) = 0
+   test $(grep -c "X-Mailer-Send-Delay:" stdout) = 2
 '
 
 test_expect_success $PREREQ '--send-delay adds a X-Mailer-Send-Delay header to 
affected E-Mails' '
-- 
2.16.2.804.g6dcf76e118

[PATCH 2/2] send-email: supply a --send-delay=1 by default

[Ævar Arnfjörð Bjarmason]

The earlier change to add this option described the problem this
option is trying to solve.

This turns it on by default with a value of 1 second, which'll
hopefully solve it, and if not user reports as well as the
X-Mailer-Send-Delay header should help debug it.

I think the trade-off of slowing down E-Mail sending to turn this on
makes sense because:

 * GMail is a really common client, git.git's own unique authors by
   %aE are ~30% @gmail.com, ~20% for linux.git. That's just patch
   submitters, my guess is this it's much more common among those who
   mostly read the list, and those users who aren't using mu4e / mutt
   etc. anyway.

 * There's really no point in having this feature at all if it's not
   made the default, since the entire point is to be able to read a
   list like the git ML or the LKML and have patches from others show
   up in order.

 * I don't think anyone's really sensitive to the sending part of
   send-email taking longer. You just choose "all" and then switch to
   another terminal while it does its thing if you have a huge series,
   and for 1-3 patches I doubt anyone would notice this anyway.

Signed-off-by: Ævar Arnfjörð Bjarmason 
---
 Documentation/config.txt | 13 -
 git-send-email.perl  |  1 +
 t/t9001-send-email.sh|  4 ++--
 3 files changed, 15 insertions(+), 3 deletions(-)

diff --git a/Documentation/config.txt b/Documentation/config.txt
index f155d349c0..bd578642c1 100644
--- a/Documentation/config.txt
+++ b/Documentation/config.txt
@@ -3070,7 +3070,18 @@ sendemail.smtpReloginDelay::
 
 sendemail.smtpSendDelay::
Seconds wait in between message sending before sending another
-   message. Set it to 0 to impose no extra delay, defaults to 0.
+   message. Set it to 0 to impose no extra delay, defaults to 1
+   to wait 1 second.
++
+The reason for imposing a default delay is because certain popular
+E-Mail clients such as Google's GMail completely ignore the "Date"
+header, which format-patch is careful to set such that the patches
+will be displayed in order, and instead sort by the time the E-mail
+was received.
++
+This causes sent E-Mail to be shown completely out of order in such
+clients, imposing the delay is a workaround that should usually work
+(although it's by no means guaranteed).
 +
 See also the `--send-delay` option of linkgit:git-send-email[1].
 
diff --git a/git-send-email.perl b/git-send-email.perl
index 013277ede2..ddbc44f1c9 100755
--- a/git-send-email.perl
+++ b/git-send-email.perl
@@ -489,6 +489,7 @@ die sprintf(__("Unknown --confirm setting: '%s'\n"), 
$confirm)
unless $confirm =~ /^(?:auto|cc|compose|always|never)/;
 die sprintf(__("Invalid --send-delay setting: '%s'\n"), $send_delay)
if defined $send_delay and $send_delay !~ /^[0-9]+$/s;
+$send_delay = 1 unless defined $send_delay;
 
 # Debugging, print out the suppressions.
 if (0) {
diff --git a/t/t9001-send-email.sh b/t/t9001-send-email.sh
index fafa61c5d6..1580e00fce 100755
--- a/t/t9001-send-email.sh
+++ b/t/t9001-send-email.sh
@@ -1713,7 +1713,7 @@ test_expect_success '--send-delay expects whole 
non-negative seconds' '
test_i18ngrep "Invalid --send-delay setting" errors
 '
 
-test_expect_success $PREREQ "there is no default --send-delay" '
+test_expect_success $PREREQ "there is a default --send-delay" '
clean_fake_sendmail &&
rm -fr outdir &&
git format-patch -3 -o outdir &&
@@ -1724,7 +1724,7 @@ test_expect_success $PREREQ "there is no default 
--send-delay" '
outdir/*.patch \
2>stderr >stdout &&
test $(grep -c "X-Mailer:" stdout) = 3 &&
-   test $(grep -c "X-Mailer-Send-Delay:" stdout) = 0
+   test $(grep -c "X-Mailer-Send-Delay:" stdout) = 2
 '
 
 test_expect_success $PREREQ '--send-delay adds a X-Mailer-Send-Delay header to 
affected E-Mails' '
-- 
2.16.2.804.g6dcf76e118