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