On Tue, Aug 14, 2018 at 11:15 AM Ævar Arnfjörð Bjarmason <avarab@xxxxxxxxx> wrote: > > Add a --send-delay option with a corresponding sendemail.smtpSendDelay > configuration variable. When set to e.g. 2, this causes send-email to > sleep 2 seconds before sending the next E-Mail. We'll only sleep > between sends, not before the first send, or after the last. > > This option has two uses. Firstly, to be able to Ctrl+C a long send > with "all" if you have a change of heart. Secondly, as a hack in some > mail setups to, with a sufficiently high delay, force the receiving > client to sort the E-Mails correctly. > > Some popular E-Mail clients completely ignore the "Date" header, which > format-patch is careful to set such that the patches will be displayed > in order, and instead sort by the time the E-mail was received. > > Google's GMail is a good example of such a client. It ostensibly sorts > by some approximation of received time (although not by any "Received" > header). It's more usual than not to see patches showing out of order > in GMail. To take a few examples of orders seen on patches on the Git > mailing list: > > 1 -> 3 -> 4 -> 2 -> 8 -> 7 (completion by Nguyễn Thái Ngọc Duy) > 2 -> 0 -> 1 -> 3 (pack search by Derrick Stolee) > 3 -> 2 -> 1 (fast-import by Jameson Miller) > 2 -> 3 -> 1 -> 5 -> 4 -> 6 (diff-highlight by Jeff King) > > The reason to add the new "X-Mailer-Send-Delay" header is to make it > easy to tell what the imposed delay was, if any. This allows for > gathering some data on how the transfer of E-Mails with & without this > option behaves. This may not be workable without really long delays, > see [1] and [2]. > > The reason for why the getopt format is "send-delay=s" instead of > "send-delay=d" is because we're doing manual validation of the value > we get passed, which getopt would corrupt in cases of e.g. float > values before we could show a sensible error message. > > 1. https://public-inbox.org/git/20180325210132.GE74743@xxxxxxxxxxxxxxxxxxxxxxxxxx/ > 2. https://public-inbox.org/git/xmqqpo3rehe4.fsf@xxxxxxxxxxxxxxxxxxxxxxxxx/ > > Signed-off-by: Ævar Arnfjörð Bjarmason <avarab@xxxxxxxxx> > --- > > I submitted this back in March hoping it would solve mail ordering > problems, but the other motive I had for this is that I'm paranoid > that I'm sending out bad E-Mails, and tend to "y" to each one because > "a" is too fast.' Heh. GMail seems to have added an Undo button in their UI, which would be the same feature as this one. (Hit Ctrl+C in time to "undo" the sending command) I have been bitten quite a few times by using "a" as I had old series still laying around, such that it would send a new series and parts of the old series (or when you changed subjects and resend another iteration of a series, you may end up with two "patch 1"s). So I learned to be careful before pressing "a" on sending. Maybe the underlying issue is that you really only want to send a series and not "all" as send-email asks for. So maybe that dialog could learn a [s]eries switch, which would check either filenames to count up, or if the base that is recorded (base-commit for first and prerequisite-patch-id for followups) is consistent. Send this email? ([y]es|[n]o|[e]dit|[q]uit|[a]ll|[s]eries): Another note: I personally never use no/quit, but Ctrl+C for both cases. This is also different than the feature of 5453b83bdf9 (send-email --batch-size to work around some SMTP server limit, 2017-05-21) which introduced sendemail.smtpReloginDelay, which would offer the same functionality when the batch-size is set to 1. (Although this would keep you connected to the server as well as add the X-Mailer-Send-Delay header, which is nothing from the official email RFC, but your own invention?) Having sorted mails in GMail would be nice! Thanks, Stefan
