[PATCH] send-mail: Add option to sleep between sending each email.

[PATCH] send-mail: Add option to sleep between sending each email.

[Georgi Chorbadzhiyski]

Sometimes when sending lots of changes it is not nice
to send emails as fast as possible. Of course you can
confirm each email after waiting couple of seconds but
this is not optimal. This patch adds --sleep option
to git-send-mail and corresponding sendmail.sleep config
variable to control how much seconds to wait between
sending each email. The default is 0 (not wait at all).

Signed-off-by: Georgi Chorbadzhiyski <gf@unixsol.org>
---
 Documentation/git-send-email.txt |    6 ++++++
 git-send-email.perl              |   13 ++++++++++++-
 2 files changed, 18 insertions(+), 1 deletions(-)

diff --git a/Documentation/git-send-email.txt b/Documentation/git-send-email.txt
index 327233c..2ceb69f 100644
--- a/Documentation/git-send-email.txt
+++ b/Documentation/git-send-email.txt
@@ -298,6 +298,9 @@ Default is the value of 'sendemail.confirm' configuration value; if that
 is unspecified, default to 'auto' unless any of the suppress options
 have been specified, in which case default to 'compose'.
 
+--sleep=<seconds>::
+	How many seconds to wait between sending each email.
+
 --dry-run::
 	Do everything except actually send the emails.
 
@@ -349,6 +352,9 @@ sendemail.confirm::
 	one of 'always', 'never', 'cc', 'compose', or 'auto'. See '--confirm'
 	in the previous section for the meaning of these values.
 
+sendemail.sleep::
+	Sets how many seconds to wait between sending each email.
+
 EXAMPLE
 -------
 Use gmail as the smtp server
diff --git a/git-send-email.perl b/git-send-email.perl
index 98ab33a..7239fd4 100755
--- a/git-send-email.perl
+++ b/git-send-email.perl
@@ -84,6 +84,7 @@ git send-email [options] <file | directory | rev-list options >
   Administering:
     --confirm               <str>  * Confirm recipients before sending;
                                      auto, cc, compose, always, or never.
+    --sleep                 <int>  * Sleep <int> seconds between sending mails.
     --quiet                        * Output one line of info per email.
     --dry-run                      * Don't actually send the emails.
     --[no-]validate                * Perform patch sanity checks. Default on.
@@ -195,7 +196,7 @@ my ($to_cmd, $cc_cmd);
 my ($smtp_server, $smtp_server_port, @smtp_server_options);
 my ($smtp_authuser, $smtp_encryption);
 my ($identity, $aliasfiletype, @alias_files, $smtp_domain);
-my ($validate, $confirm);
+my ($validate, $confirm, $sleep);
 my (@suppress_cc);
 my ($auto_8bit_encoding);
 
@@ -230,6 +231,7 @@ my %config_settings = (
     "envelopesender" => \$envelope_sender,
     "multiedit" => \$multiedit,
     "confirm"   => \$confirm,
+    "sleep" => \$sleep,
     "from" => \$sender,
     "assume8bitencoding" => \$auto_8bit_encoding,
 );
@@ -304,6 +306,7 @@ my $rc = GetOptions("sender|from=s" => \$sender,
 		    "suppress-cc=s" => \@suppress_cc,
 		    "signed-off-cc|signed-off-by-cc!" => \$signed_off_by_cc,
 		    "confirm=s" => \$confirm,
+		    "sleep:i" => \$sleep,
 		    "dry-run" => \$dry_run,
 		    "envelope-sender=s" => \$envelope_sender,
 		    "thread!" => \$thread,
@@ -405,6 +408,9 @@ if ($confirm_unconfigured) {
 die "Unknown --confirm setting: '$confirm'\n"
 	unless $confirm =~ /^(?:auto|cc|compose|always|never)/;
 
+# Set sleep's default value
+$sleep = 0 if (!defined $sleep);
+
 # Debugging, print out the suppressions.
 if (0) {
 	print "suppressions:\n";
@@ -1143,6 +1149,11 @@ X-Mailer: git-send-email $gitversion
 		}
 	}
 
+	if (!$dry_run && $sleep) {
+		print "Sleeping: $sleep second(s).\n" if (!$quiet);
+		sleep($sleep);
+	};
+
 	return 1;
 }
 
-- 
1.7.5.1

Re: [PATCH] send-mail: Add option to sleep between sending each email.

[Ramkumar Ramachandra]

Hi Georgi,

Georgi Chorbadzhiyski writes:
> Sometimes when sending lots of changes it is not nice
> to send emails as fast as possible. Of course you can
> confirm each email after waiting couple of seconds but
> this is not optimal. This patch adds --sleep option
> to git-send-mail and corresponding sendmail.sleep config
> variable to control how much seconds to wait between
> sending each email. The default is 0 (not wait at all).

I use git-send-email a lot, and I ask it to print out the list of all
emails once before confirming.  After confirming, I just switch back
to Emacs and continue work- in the many instances, I've never actually
needed to slow the process down.  If anything, I wished it could
concurrently send many emails and do things /faster/ *.   I'm a little
curious about why you want to slow it down- is your SMTP server
configured to block you because it suspects that you're trying to
spam?

Thanks.

* I first need to see if SMTP servers today can take in emails at this
speed without suspecting spam.

-- Ram

Re: [PATCH] send-mail: Add option to sleep between sending each email.

[Matthieu Moy]

Ramkumar Ramachandra <artagnon@gmail.com> writes:

> I'm a little curious about why you want to slow it down- is your SMTP
> server configured to block you because it suspects that you're trying
> to spam?

There have been discussion (and IIRC a patch) proposing this already in
the past. One advantage of sleeping a bit between each email is that it
increase the chances for the receiver to receive the emails in the right
order.

-- 
Matthieu Moy
http://www-verimag.imag.fr/~moy/

Re: [PATCH] send-mail: Add option to sleep between sending each email.

[Georgi Chorbadzhiyski]

Around 09/08/2011 11:43 AM, Ramkumar Ramachandra scribbled:
> Hi Georgi,
> 
> Georgi Chorbadzhiyski writes:
>> Sometimes when sending lots of changes it is not nice
>> to send emails as fast as possible. Of course you can
>> confirm each email after waiting couple of seconds but
>> this is not optimal. This patch adds --sleep option
>> to git-send-mail and corresponding sendmail.sleep config
>> variable to control how much seconds to wait between
>> sending each email. The default is 0 (not wait at all).
> 
> I use git-send-email a lot, and I ask it to print out the list of all
> emails once before confirming.  After confirming, I just switch back
> to Emacs and continue work- in the many instances, I've never actually
> needed to slow the process down.  If anything, I wished it could
> concurrently send many emails and do things /faster/ *.   I'm a little
> curious about why you want to slow it down- is your SMTP server
> configured to block you because it suspects that you're trying to
> spam?
> 
> Thanks.
> 
> * I first need to see if SMTP servers today can take in emails at this
> speed without suspecting spam.

It is not the mail server, it is workaround mainly for web archives and
MUAs that look at received dates when sorting threads.

When they receive a lot of email in one thread very quickly (and out of
order) they do not thread correctly.

See for example this: http://mailman.videolan.org/pipermail/dvblast-devel/2011-August/thread.html
The thread named: [dvblast-devel] [PATCH 0/4] Post git migration changes
See how 1,3,4/4 are not detected to be part of the thread even when
all headers are set correctly by git-send-email.

Probably my mail server send them out of order and that is why I have
the idea to introduce some small delay between sending each email. Easier
on the MTA, works around the possibility to send emails out of order
the flip side is that it takes more time.

-- 
Georgi Chorbadzhiyski
http://georgi.unixsol.org/

Re: [PATCH] send-mail: Add option to sleep between sending each email.

[Ramkumar Ramachandra]

Hi Matthieu and Georgi,

Matthieu Moy writes:
> There have been discussion (and IIRC a patch) proposing this already in
> the past. One advantage of sleeping a bit between each email is that it
> increase the chances for the receiver to receive the emails in the right
> order.

Ah, it looks like I missed the earlier discussion/ patch- sorry.  Yes,
I've also wondered what to do about the order in which patches appear
in reply to the cover letter- I was of the opinion that it was a minor
inconvenience that we have to put up with that until SMTP servers
learn to fix these things.  Slowing things down a little bit for now
until they catch up is probably a good idea.

Georgi Chorbadzhiyski writes:
> See for example this: http://mailman.videolan.org/pipermail/dvblast-devel/2011-August/thread.html
> The thread named: [dvblast-devel] [PATCH 0/4] Post git migration changes
> See how 1,3,4/4 are not detected to be part of the thread even when
> all headers are set correctly by git-send-email.

This is a far more serious problem.  For this, I was toying with the
idea of special cover-letter handling in git-send-email.  My idea was
that it should essentially send the cover letter, wait for a second
and then send all the other emails concurrently.  Sure, slowing the
entire process down would work too, but it's not so elegant.

Thanks.

-- Ram

Re: [PATCH] send-mail: Add option to sleep between sending each email.

[Ramkumar Ramachandra]

Hi again,

Ramkumar Ramachandra writes:
> [...]
> Yes,
> I've also wondered what to do about the order in which patches appear
> in reply to the cover letter- I was of the opinion that it was a minor
> inconvenience that we have to put up with that until SMTP servers
> learn to fix these things.

Another small thought- it'll probably be a good idea to teach
interfaces like Gmane and your email client some special rules: If the
X-Mailer is git-send-email or if the subject field matches [.*PATCH
(\d+)/\d+], sort the email thread by \1.  Thoughts?

Thanks.

-- Ram

Re: [PATCH] send-mail: Add option to sleep between sending each email.

[Ramkumar Ramachandra]

Hi,

I mocked up a small patch to demonstrate the "special cover letter
handling" idea.  Let me know if you think it's worth pursuing.
Warning: Untested.

Signed-off-by: Ramkumar Ramachandra <artagnon@gmail.com>

-- 8< --
diff --git a/git-send-email.perl b/git-send-email.perl
index 98ab33a..30b8651 100755
--- a/git-send-email.perl
+++ b/git-send-email.perl
@@ -80,6 +80,7 @@ git send-email [options] <file | directory |
rev-list options >
     --[no-]suppress-from           * Send to self. Default off.
     --[no-]chain-reply-to          * Chain In-Reply-To: fields. Default off.
     --[no-]thread                  * Use In-Reply-To: field. Default on.
+    --[no-]initial-wait     <int>  * Wait <int> seconds after sending
first email.

   Administering:
     --confirm               <str>  * Confirm recipients before sending;
@@ -190,7 +191,7 @@ sub do_edit {
 }

 # Variables with corresponding config settings
-my ($thread, $chain_reply_to, $suppress_from, $signed_off_by_cc);
+my ($thread, $initial_wait, $chain_reply_to, $suppress_from,
$signed_off_by_cc);
 my ($to_cmd, $cc_cmd);
 my ($smtp_server, $smtp_server_port, @smtp_server_options);
 my ($smtp_authuser, $smtp_encryption);
@@ -205,6 +206,7 @@ my $not_set_by_user = "true but not set by the user";

 my %config_bool_settings = (
     "thread" => [\$thread, 1],
+    "initialwait" => [\$initial_wait, 0],
     "chainreplyto" => [\$chain_reply_to, $not_set_by_user],
     "suppressfrom" => [\$suppress_from, undef],
     "signedoffbycc" => [\$signed_off_by_cc, undef],
@@ -1141,6 +1143,11 @@ X-Mailer: git-send-email $gitversion
 		} else {
 			print "Result: OK\n";
 		}
+		if ($initial_wait) {
+			print "Sleeping: $initial_wait seconds.\n" if (!$quiet);
+			sleep($initial_wait);
+			$initial_wait = 0;
+		}
 	}

 	return 1;

Re: [PATCH] send-mail: Add option to sleep between sending each email.

[Georgi Chorbadzhiyski]

Around 09/08/2011 01:44 PM, Ramkumar Ramachandra scribbled:
> I mocked up a small patch to demonstrate the "special cover letter
> handling" idea.  Let me know if you think it's worth pursuing.
> Warning: Untested.
> 
> Signed-off-by: Ramkumar Ramachandra <artagnon@gmail.com>
> 
> -- 8< --
> diff --git a/git-send-email.perl b/git-send-email.perl
> index 98ab33a..30b8651 100755
> --- a/git-send-email.perl
> +++ b/git-send-email.perl
> @@ -80,6 +80,7 @@ git send-email [options] <file | directory |
> rev-list options >
>      --[no-]suppress-from           * Send to self. Default off.
>      --[no-]chain-reply-to          * Chain In-Reply-To: fields. Default off.
>      --[no-]thread                  * Use In-Reply-To: field. Default on.
> +    --[no-]initial-wait     <int>  * Wait <int> seconds after sending
> first email.
> 
>    Administering:
>      --confirm               <str>  * Confirm recipients before sending;
> @@ -190,7 +191,7 @@ sub do_edit {
>  }
> 
>  # Variables with corresponding config settings
> -my ($thread, $chain_reply_to, $suppress_from, $signed_off_by_cc);
> +my ($thread, $initial_wait, $chain_reply_to, $suppress_from,
> $signed_off_by_cc);
>  my ($to_cmd, $cc_cmd);
>  my ($smtp_server, $smtp_server_port, @smtp_server_options);
>  my ($smtp_authuser, $smtp_encryption);
> @@ -205,6 +206,7 @@ my $not_set_by_user = "true but not set by the user";
> 
>  my %config_bool_settings = (
>      "thread" => [\$thread, 1],
> +    "initialwait" => [\$initial_wait, 0],
>      "chainreplyto" => [\$chain_reply_to, $not_set_by_user],
>      "suppressfrom" => [\$suppress_from, undef],
>      "signedoffbycc" => [\$signed_off_by_cc, undef],
> @@ -1141,6 +1143,11 @@ X-Mailer: git-send-email $gitversion
>  		} else {
>  			print "Result: OK\n";
>  		}
> +		if ($initial_wait) {
> +			print "Sleeping: $initial_wait seconds.\n" if (!$quiet);
> +			sleep($initial_wait);
> +			$initial_wait = 0;
> +		}
>  	}
> 
>  	return 1;

I don't see how this would solve the problem that MTA can send
emails after the first one out of order.

-- 
Georgi Chorbadzhiyski
http://georgi.unixsol.org/

Re: [PATCH] send-mail: Add option to sleep between sending each email.

[Matthieu Moy]

Ramkumar Ramachandra <artagnon@gmail.com> writes:

> Hi,
>
> I mocked up a small patch to demonstrate the "special cover letter
> handling" idea.  Let me know if you think it's worth pursuing.

If it was really a problem to have to wait a few seconds/minutes more,
I'd consider it as an interesting compromise (allow [PATCH 1/2] to come
after [PATCH 2/2] but make sure they both come after the coverletter to
make sure the recipient notice they're part of the same thread).

But quite frankly, I don't think it's worth the trouble.

As you said, the normal workflow is to use "git send-email", and go back
to work after, so you can do something else while the emails are being
sent (see below [1]). I don't think bothering users with --sleep and
--initial-wait is worth the benefit of having both possibilities. People
worried about email order should be fine with --sleep.

[1] Actually, I think there's a problem with Georgi's patch. If I read
correctly, the sleep is inserted within the confirmation loop, which
means the user will have

send this email? yes
sending email
sleeping 10 seconds
send this email? yes
sending email
sleeping 10 seconds
...

while it should be

send this email? yes
ok, I'll send it later
send this email? yes
ok, I'll send it later
sending first email ...
sleeping 10 seconds
sending second email
done.

(i.e. don't force the user to wait between confirmations, and don't wait
after the last email)

-- 
Matthieu Moy
http://www-verimag.imag.fr/~moy/

Re: [PATCH] send-mail: Add option to sleep between sending each email.

[Georgi Chorbadzhiyski]

Around 09/08/2011 02:15 PM, Matthieu Moy scribbled:
> [1] Actually, I think there's a problem with Georgi's patch. If I read
> correctly, the sleep is inserted within the confirmation loop, which
> means the user will have
> 
> send this email? yes
> sending email
> sleeping 10 seconds
> send this email? yes
> sending email
> sleeping 10 seconds
> ...
> 
> while it should be
> 
> send this email? yes
> ok, I'll send it later
> send this email? yes
> ok, I'll send it later
> sending first email ...
> sleeping 10 seconds
> sending second email
> done.
> 
> (i.e. don't force the user to wait between confirmations, and don't wait
> after the last email)

In order for this to work, confirmation should be split from send_message()
and from a quick look this not seem very easy. Might be easier to just
disable the sleep if user was asked for confirmation. It'll be good to
not sleep after last email, but main "foreach my $t (@files) {" loop should
pass some hint to send_message().

-- 
Georgi Chorbadzhiyski
http://georgi.unixsol.org/

Re: [PATCH] send-mail: Add option to sleep between sending each email.

[Georgi Chorbadzhiyski]

[-- Attachment #1: Type: text/plain, Size: 1218 bytes --]

Around 09/08/2011 04:58 PM, Georgi Chorbadzhiyski scribbled:
> Around 09/08/2011 02:15 PM, Matthieu Moy scribbled:
>> [1] Actually, I think there's a problem with Georgi's patch. If I read
>> correctly, the sleep is inserted within the confirmation loop, which
>> means the user will have
>>
>> send this email? yes
>> sending email
>> sleeping 10 seconds
>> send this email? yes
>> sending email
>> sleeping 10 seconds
>> ...
>>
>> while it should be
>>
>> send this email? yes
>> ok, I'll send it later
>> send this email? yes
>> ok, I'll send it later
>> sending first email ...
>> sleeping 10 seconds
>> sending second email
>> done.
>>
>> (i.e. don't force the user to wait between confirmations, and don't wait
>> after the last email)
> 
> In order for this to work, confirmation should be split from send_message()
> and from a quick look this not seem very easy. Might be easier to just
> disable the sleep if user was asked for confirmation. It'll be good to
> not sleep after last email, but main "foreach my $t (@files) {" loop should
> pass some hint to send_message().

The attached patch (apply on on top of the original) should implement the
idea.

-- 
Georgi Chorbadzhiyski
http://georgi.unixsol.org/

[-- Attachment #2: send-email-sleep-fix1.diff --]
[-- Type: text/plain, Size: 399 bytes --]

diff --git a/git-send-email.perl b/git-send-email.perl
index 7239fd4..d4559c9 100755
--- a/git-send-email.perl
+++ b/git-send-email.perl
@@ -1149,7 +1149,7 @@ X-Mailer: git-send-email $gitversion
 		}
 	}
 
-	if (!$dry_run && $sleep) {
+	if (!$dry_run && $sleep && $message_num < scalar $#files && $confirm eq 'never') {
 		print "Sleeping: $sleep second(s).\n" if (!$quiet);
 		sleep($sleep);
 	};

Re: [PATCH] send-mail: Add option to sleep between sending each email.

[Junio C Hamano]

Matthieu Moy <Matthieu.Moy@grenoble-inp.fr> writes:

> There have been discussion (and IIRC a patch) proposing this already in
> the past. One advantage of sleeping a bit between each email is that it
> increase the chances for the receiver to receive the emails in the right
> order.

Huh? Even in the presense of MTAs in the middle that are free to reorder
messages?

IIRC, "git send-email" does its best to force ordering by assigning
monotonically increasing timestamps on the Date: field, so that the
recipients can sort the messages based on it, in addition to the
In-Reply-To field to help threading. I personally do not think there is
anything more than that that should done in the program.

Re: [PATCH] send-mail: Add option to sleep between sending each email.

[Georgi Chorbadzhiyski]

On 9/8/11 8:10 PM, Jakub Narebski wrote:
> Georgi Chorbadzhiyski<gf@unixsol.org>  writes:
>> Around 09/08/2011 04:58 PM, Georgi Chorbadzhiyski scribbled:
> [...]
>>> In order for this to work, confirmation should be split from send_message()
>>> and from a quick look this not seem very easy. Might be easier to just
>>> disable the sleep if user was asked for confirmation. It'll be good to
>>> not sleep after last email, but main "foreach my $t (@files) {" loop should
>>> pass some hint to send_message().
>>
>> The attached patch (apply on on top of the original) should implement the
>> idea.
>>
>> --
>> Georgi Chorbadzhiyski
>> http://georgi.unixsol.org/
>> diff --git a/git-send-email.perl b/git-send-email.perl
>> index 7239fd4..d4559c9 100755
>> --- a/git-send-email.perl
>> +++ b/git-send-email.perl
>> @@ -1149,7 +1149,7 @@ X-Mailer: git-send-email $gitversion
>>   		}
>>   	}
>>
>> -	if (!$dry_run&&  $sleep) {
>> +	if (!$dry_run&&  $sleep&&  $message_num<  scalar $#files&&  $confirm eq 'never') {
>                                                    ^^^^^^^^^^^^^^
>
>>   		print "Sleeping: $sleep second(s).\n" if (!$quiet);
>>   		sleep($sleep);
>>   	};
>
> Errr... what?  If we have @files array, then '$#files' is index of
> last element in array, which is scalar anyway, and 'scalar $#files' is
> a no-op.
>
> You can get number of elements in array with 'scalar @files', though
> _implicit_ scalar context would also work, like e.g. right hand side
> of '<' operator.

Correct, my perl is rusty and I wasn't sure $#xx was what I needed so
so I copied it from "$time = time - scalar $#files;" somewhere in
the same file.

-- 
Georgi Chorbadzhiyski
http://georgi.unixsol.org/

Re: [PATCH] send-mail: Add option to sleep between sending each email.

[Matthieu Moy]

Junio C Hamano <gitster@pobox.com> writes:

> Matthieu Moy <Matthieu.Moy@grenoble-inp.fr> writes:
>
>> There have been discussion (and IIRC a patch) proposing this already in
>> the past. One advantage of sleeping a bit between each email is that it
>> increase the chances for the receiver to receive the emails in the right
>> order.
>
> Huh? Even in the presense of MTAs in the middle that are free to reorder
> messages?

I didn't say it _ensures_ reception in the right order. I said it
increases the chances.

-- 
Matthieu Moy
http://www-verimag.imag.fr/~moy/

Re: [PATCH] send-mail: Add option to sleep between sending each email.

[mfwitten]

On Thu, 08 Sep 2011 10:12:46 -0700, Junio C Hamano wrote:

> Matthieu Moy <Matthieu.Moy@grenoble-inp.fr> writes:
>
>> There have been discussion (and IIRC a patch) proposing this already in
>> the past. One advantage of sleeping a bit between each email is that it
>> increase the chances for the receiver to receive the emails in the right
>> order.
>
> Huh? Even in the presense of MTAs in the middle that are free to reorder
> messages?
>
> IIRC, "git send-email" does its best to force ordering by assigning
> monotonically increasing timestamps on the Date: field, so that the
> recipients can sort the messages based on it, in addition to the
> In-Reply-To field to help threading. I personally do not think there is
> anything more than that that should done in the program.

The previous, rather lengthy discussion involved my patch and took place
over 2 years ago. The thread starts here:

  Message-ID: <1239139522-24118-1-git-send-email-mfwitten@gmail.com?
  http://thread.gmane.org/gmane.comp.version-control.git/115988

continues here (because of my email header mistake):

  Message-ID: <49dcb464.06d7720a.66ca.ffffbd30@mx.google.com>
  http://thread.gmane.org/gmane.comp.version-control.git/116083

and ultimately, the final patch review was proferred here:

  Message-Id: <1239647037-15381-11-git-send-email-mfwitten@gmail.com>
  http://article.gmane.org/gmane.comp.version-control.git/116471

>From a quick glance, my patch would appear to have become more advanced,
as per your own request, Junio:

  Message-ID: <7vskkh1va5.fsf@gitster.siamese.dyndns.org>
  http://thread.gmane.org/gmane.comp.version-control.git/116083

Here's the documentation I wrote for it:

  diff --git a/Documentation/git-send-email.txt b/Documentation/git-send-email.txt
  index 5f7d640..236e578 100644
  --- a/Documentation/git-send-email.txt
  +++ b/Documentation/git-send-email.txt
  @@ -178,6 +178,36 @@ Automating
   	cc list. Default is the value of 'sendemail.signedoffbycc' configuration
   	value; if that is unspecified, default to --signed-off-by-cc.
   
  +--sleep=<seconds>[,<burst>]::
  +	This option specfies that send-email should sleep for <seconds>
  +	after sending <burst> messages as quickly as possible; <seconds>
  +	should be an integer >= 0 and <burst> should be an integer >= 1.
  +	This mode of operation attacks 2 problems: email throttling and
  +	arrival disorder. Default is the value of the 'sendemail.sleep'
  +	configuration variable, or '0' if that does not exist.
  ++
  +By default, send-email tries to send one patch per email as quickly as
  +possible. Unfortunately, some email services restrict a user by refusing
  +to send more than some maximum number of email messages, M, in a given
  +period of seconds, S. This can be troublesome if the patch series has
  +more than M patches, because the server will ultimately refuse to send
  +some of them. In this case, simply pass '--sleep=S,M' or '--sleep S,M'
  +or set sendemail.sleep to 'S,M'.
  ++
  +Moreover, the emails often arrive at the final destination out of order;
  +though send-email manipulates the date fields and usually chains subsequent
  +emails via the In-Reply-To headers, some mail viewers nevertheless insist
  +on presenting them by order of arrival. This may be mitigated by using
  +something like '--sleep 60' (the equivalent of '--sleep 60,1'), so that
  +there is a 60 second delay between sending any two messages.
  ++
  +*Note*: Because of varying routes and batching schemes, there is no delay
  +that can guarantee the correct arrival order. Obviously, one solution is to
  +choose an obscenely large number, so be prepared to run send-email in the
  +background. Of course, spreading emails across time makes it more likely
  +that unrelated email messages arrive between patches. Therefore, send-email
  +warns you if both --sleep and --no-chain-reply-to are used.
  +
   --suppress-cc=<category>::
   	Specify an additional category of recipients to suppress the
   	auto-cc of:

Sincerely,
Michael Witten

Re: [PATCH] send-mail: Add option to sleep between sending each email.

[Ramkumar Ramachandra]

Hi,

Michael Witten writes:
> [...]
> From a quick glance, my patch would appear to have become more advanced,
> as per your own request, Junio:
>
>  Message-ID: <7vskkh1va5.fsf@gitster.siamese.dyndns.org>
>  http://thread.gmane.org/gmane.comp.version-control.git/116083

Wow, that was over two years ago.  I only started contributing to Git
a little over a year and a half ago: no wonder I missed the
discussion.  Thanks for digging it out.

Junio C Hamano writes:
> [...]
> IIRC, "git send-email" does its best to force ordering by assigning
> monotonically increasing timestamps on the Date: field, so that the
> recipients can sort the messages based on it, in addition to the
> In-Reply-To field to help threading. I personally do not think there is
> anything more than that that should done in the program.

I agree with Junio here.  However, I realize that the patch adds some
value: perhaps we can have it as a script under 'contrib/'?

Thanks.

-- Ram

Re: [PATCH] send-mail: Add option to sleep between sending each email.

[Jakub Narebski]

Georgi Chorbadzhiyski <gf@unixsol.org> writes:
> Around 09/08/2011 04:58 PM, Georgi Chorbadzhiyski scribbled:
[...]
> > In order for this to work, confirmation should be split from send_message()
> > and from a quick look this not seem very easy. Might be easier to just
> > disable the sleep if user was asked for confirmation. It'll be good to
> > not sleep after last email, but main "foreach my $t (@files) {" loop should
> > pass some hint to send_message().
> 
> The attached patch (apply on on top of the original) should implement the
> idea.
> 
> -- 
> Georgi Chorbadzhiyski
> http://georgi.unixsol.org/
> diff --git a/git-send-email.perl b/git-send-email.perl
> index 7239fd4..d4559c9 100755
> --- a/git-send-email.perl
> +++ b/git-send-email.perl
> @@ -1149,7 +1149,7 @@ X-Mailer: git-send-email $gitversion
>  		}
>  	}
>  
> -	if (!$dry_run && $sleep) {
> +	if (!$dry_run && $sleep && $message_num < scalar $#files && $confirm eq 'never') {
                                                  ^^^^^^^^^^^^^^

>  		print "Sleeping: $sleep second(s).\n" if (!$quiet);
>  		sleep($sleep);
>  	};

Errr... what?  If we have @files array, then '$#files' is index of
last element in array, which is scalar anyway, and 'scalar $#files' is
a no-op.

You can get number of elements in array with 'scalar @files', though
_implicit_ scalar context would also work, like e.g. right hand side
of '<' operator.

-- 
Jakub Narębski