On Thu, 08 Sep 2011 10:12:46 -0700, Junio C Hamano wrote: > Matthieu Moy <Matthieu.Moy@xxxxxxxxxxxxxxx> 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@xxxxxxxxx? http://thread.gmane.org/gmane.comp.version-control.git/115988 continues here (because of my email header mistake): Message-ID: <49dcb464.06d7720a.66ca.ffffbd30@xxxxxxxxxxxxx> 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@xxxxxxxxx> 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@xxxxxxxxxxxxxxxxxxxxxxxxxx> 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 -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html