On Fri, Jun 07, 2013 at 12:12:52PM +0200, Erik Faye-Lund wrote: > > Yeah, if it were mingw_raise responsible for this, I would suggest using > > the POSIX shell "128+sig" instead. We could potentially check for > > SIG_DFL[1] mingw_raise and intercept and exit there. I don't know if > > that would create headaches or confusion for other msys programs, > > though. I'd leave that up to the msysgit people to decide whether it is > > worth the trouble. > > > > ...and here's the code to do just that: > [...] > @@ -1715,6 +1720,13 @@ int mingw_raise(int sig) > sigint_fn(SIGINT); > return 0; > > + case SIGTERM: > + if (sigterm_fn == SIG_DFL) > + exit(128 + SIGTERM); > + else if (sigterm_fn != SIG_IGN) > + sigterm_fn(SIGTERM); > + return 0; I'm a little negative on handling just SIGTERM. That would make the test pass, but does it really address the overall issue? To me, the usefulness is having exit values with consistent meanings. Imagine I run a very large git hosting site, and I want to log exceptional conditions (e.g., a git sub-process crashes). What exit code do I get from a SIGSEGV or SIGBUS (or GPF, or whatever Windows calls these)? On Unix systems, this is pretty easy. To be honest, I do not care that much about Windows systems because I would not host a large site on it. :) But IMHO, the point of such a scheme is to be consistent across all signals. -Peff -- 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