From mboxrd@z Thu Jan 1 00:00:00 1970 From: Jeff King Subject: Re: RFC: git send-email and error handling Date: Thu, 14 Apr 2011 17:09:13 -0400 Message-ID: <20110414210913.GC6525@sigill.intra.peff.net> References: <4DA754A4.3090709@windriver.com> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Cc: git@vger.kernel.org To: Paul Gortmaker X-From: git-owner@vger.kernel.org Thu Apr 14 23:09:21 2011 Return-path: Envelope-to: gcvg-git-2@lo.gmane.org Received: from vger.kernel.org ([209.132.180.67]) by lo.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1QATmz-0008BP-3f for gcvg-git-2@lo.gmane.org; Thu, 14 Apr 2011 23:09:21 +0200 Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752041Ab1DNVJQ (ORCPT ); Thu, 14 Apr 2011 17:09:16 -0400 Received: from 99-108-226-0.lightspeed.iplsin.sbcglobal.net ([99.108.226.0]:56406 "EHLO peff.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751764Ab1DNVJP (ORCPT ); Thu, 14 Apr 2011 17:09:15 -0400 Received: (qmail 3721 invoked by uid 107); 14 Apr 2011 21:10:06 -0000 Received: from sigill.intra.peff.net (HELO sigill.intra.peff.net) (10.0.0.7) (smtp-auth username relayok, mechanism cram-md5) by peff.net (qpsmtpd/0.84) with ESMTPA; Thu, 14 Apr 2011 17:10:06 -0400 Received: by sigill.intra.peff.net (sSMTP sendmail emulation); Thu, 14 Apr 2011 17:09:13 -0400 Content-Disposition: inline In-Reply-To: <4DA754A4.3090709@windriver.com> Sender: git-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: git@vger.kernel.org Archived-At: On Thu, Apr 14, 2011 at 04:10:12PM -0400, Paul Gortmaker wrote: > The command line (git 1.7.4.4) is typically something like: > > git send-email --to stable@kernel.org --to linux-kernel@vger.kernel.org \ > --cc stable-review@kernel.org some_patch_dir > > So, let me get to what happened today: After sending 113 out of 209 > patches, it came to the 114th patch, and gave me this: > > (mbox) Adding cc: Dmitry Torokhov from line 'From: Dmitry Torokhov ' > (body) Adding cc: Dmitry Torokhov from line 'Signed-off-by: Dmitry Torokhov ' > (body) Adding cc: Paul Gortmaker from line 'Signed-off-by: Paul Gortmaker ' > 5.2.1 ... Mailbox disabled for this recipient > > Then, taking that as a hard error, it simply exited, > leaving me scrambling to figure out how to quickly fix the > offending patch and continue with the unsent queue. I suspect part of the issue is that your mail setup is unlike that of most people. Usually, we would deliver to some local MTA (either by SMTP directly, by sendmail that speaks SMTP to a smarthost, or by sendmail that queues directly); that MTA would queue the message in a spool for you, and attempt delivery asynchronously. So the errors generally come all or nothing. You can queue mail, or you can't, and trying again and again after each error is just wasteful and annoying. Eventual errors are reported back to you as bounces. Your setup seems different; it looks like your sendmail (or the SMTP server you connect to) actually routes the mail without queueing at all, and you synchronously get the final word on whether it can be delivered. Or maybe it just connects to the recipient site and checks that "RCPT TO" works before actually queueing. It's hard to say from the snippet above. What's your MTA? I can see in your case how it would be preferable to keep going through the list and then assemble a set of errors at the end. But that should be configurable, because most setups won't want that behavior. > From my point of view, the right thing to do here would have > been to ignore the error on the harvested mail address, and continue > on through the rest of the queue. It's a little tricky, because send-email may not know the details of what happened, especially if this behavior comes from a sendmail wrapper rather than SMTP. We dump the message and a list of recipients to an external program, and then get back a "yes it was sent" or "no it was not" code. So we can't do anything clever, like say "Well, it was sent, but not to one particular address, but that's OK because that address was auto-harvested from a signed-off-by line". Whether we can do better depends on your MTA. _If_ you are sending via SMTP, and _if_ it will reject particular recipients at the time of "rcpt to", then we could do something that clever. Given that the 5.2.1 message appeared on your terminal, and that it should not have been generated by git-send-email, that implies to me you are using the local sendmail binary. > Or even interactively ask me what to do when it saw the 5.2.1 failure. > But maybe that wouldn't be right for everyone. I didn't see anything > in the GSE man page that would let me configure this behaviour either. The problem there is that the message probably was not actually sent (or at least, sendmail presumably returned an error code to git, which is why git stopped). And you, as a human, saw that the error was something survivable. But you can't just tell git "it's OK to continue". You need to actually fix the problem and re-send, which means telling git that the one particular address is not interesting. And that is a lot more interface than just yes/no. I would think what you really want is a system that tries to send everything, keeps track of which recipients are to receive which message, and then marks success or failure for each. At the end, you would find that dtor@mail.ru didn't receive anything, and realize you don't care. And you don't have to worry about restarting a failed send-email and sending duplicates. You know who got what. If that sounds good, then you should consider switching MTAs, because that is exactly what the job of an MTA is. :) -Peff