Re: Scripted clone generating an incomplete, unusable .git/config

[Jeff King <peff@peff.net>]

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