threads / patch / 28331

patchsend-mail: Add option to sleep between sending each email.

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

## tl;dr

17 messages between Sep 7, 2011 and Oct 3, 2011. Diffs are folded; open one to read it.

replies: 16people: 6as markdown or json

Georgi Chorbadzhiyski· Sep 7, 2011, 20:43 UTC · lore

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(-)
Show changes to 2 files +18 −1

Documentation/git-send-email.txt, git-send-email.perl

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
Ramkumar Ramachandra· Sep 8, 2011, 08:43 UTC · re: Georgi Chorbadzhiyski · lore

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

Hi Georgi,
Georgi Chorbadzhiyski writes:
Show 7 quoted lines
> 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
Matthieu Moy· Sep 8, 2011, 09:03 UTC · re: Ramkumar Ramachandra · lore

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

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/
Ramkumar Ramachandra· Sep 8, 2011, 09:28 UTC · re: Matthieu Moy · lore

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

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
Ramkumar Ramachandra· Sep 8, 2011, 09:35 UTC · re: Ramkumar Ramachandra · lore

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

Hi again,
Ramkumar Ramachandra writes:
Show 6 quoted lines
> [...]
> 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
Ramkumar Ramachandra· Sep 8, 2011, 10:44 UTC · re: Ramkumar Ramachandra · lore

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

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< --
Show changes to git-send-email.perl +8 −1
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;
Georgi Chorbadzhiyski· Sep 8, 2011, 10:57 UTC · re: Ramkumar Ramachandra · lore

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

Around 09/08/2011 01:44 PM, Ramkumar Ramachandra scribbled:
Show 51 quoted lines
> 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/
Matthieu Moy· Sep 8, 2011, 11:15 UTC · re: Ramkumar Ramachandra · lore

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

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/
Georgi Chorbadzhiyski· Sep 8, 2011, 13:58 UTC · re: Matthieu Moy · lore

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

Around 09/08/2011 02:15 PM, Matthieu Moy scribbled:
Show 25 quoted lines
> [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/
Georgi Chorbadzhiyski· Sep 8, 2011, 14:07 UTC · re: Georgi Chorbadzhiyski · lore

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

Around 09/08/2011 04:58 PM, Georgi Chorbadzhiyski scribbled:
Show 32 quoted lines
> 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/


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);
 	};
Jakub Narebski· Oct 3, 2011, 20:17 UTC · re: Georgi Chorbadzhiyski · lore

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

Georgi Chorbadzhiyski <gf@unixsol.org> writes:
> Around 09/08/2011 04:58 PM, Georgi Chorbadzhiyski scribbled:
[...]
Show 22 quoted lines
> > 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
Georgi Chorbadzhiyski· Sep 8, 2011, 17:14 UTC · re: Jakub Narebski · lore

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

On 9/8/11 8:10 PM, Jakub Narebski wrote:
Show 38 quoted lines
> 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/
Junio C Hamano· Sep 8, 2011, 17:12 UTC · re: Matthieu Moy · lore

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

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.

Matthieu Moy· Sep 8, 2011, 20:50 UTC · re: Junio C Hamano · lore

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

Junio C Hamano <gitster@pobox.com> writes:
Show 9 quoted lines
> 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/
mfwitten@gmail.com· Sep 9, 2011, 02:02 UTC · re: Junio C Hamano · lore

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

On Thu, 08 Sep 2011 10:12:46 -0700, Junio C Hamano wrote:
Show 15 quoted lines
> 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

Ramkumar Ramachandra· Sep 12, 2011, 05:34 UTC · re: Junio C Hamano · lore

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

Hi,
Michael Witten writes:
Show 6 quoted lines
> [...]
> 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:
Show 6 quoted lines
> [...]
> 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
Georgi Chorbadzhiyski· Sep 8, 2011, 09:11 UTC · re: Ramkumar Ramachandra · lore

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

Around 09/08/2011 11:43 AM, Ramkumar Ramachandra scribbled:
Show 24 quoted lines
> 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/

← back to recent threads