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

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 <redacted>
---
 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

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

Around 09/08/2011 11:43 AM, Ramkumar Ramachandra scribbled:

Hi Georgi,

Georgi Chorbadzhiyski writes:

quoted

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/