Ramkumar Ramachandra <artagnon@xxxxxxxxx> 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/ -- 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