On Thu, Nov 11, 2010 at 10:32:30PM -0600, Jonathan Nieder wrote: > Subject: SIGPIPE and other fatal signals should default to SIG_DFL > > The intuitive behavior when a git command receives a fatal > signal is for it to die. > > Indeed, that is the default handling. However, POSIX semantics > allow the parent of a process to override that default by > ignoring a signal, since ignored signals are preserved by fork() and > exec(). For example, Python 2.6 and 2.7's os.popen() runs a shell > with SIGPIPE ignored (Python issue 1736483). > > [...] > > check-racy.c | 1 + > daemon.c | 1 + > fast-import.c | 1 + > git.c | 2 ++ > http-backend.c | 1 + > http-fetch.c | 1 + > http-push.c | 1 + > imap-send.c | 1 + > remote-curl.c | 1 + > shell.c | 2 ++ > show-index.c | 2 ++ > upload-pack.c | 1 + > 12 files changed, 15 insertions(+), 0 deletions(-) Do we need to have it in every command? Is calling git-foo deprecated enough that we can just put it in git.c? I guess there are still a few commands that get installed explicitly in .../bin (upload-pack, for example). They would need a separate one. Perhaps it doesn't hurt to just put it in all of the non-builtins as you did. It's not that big a maintenance issue. -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