Re: Scripted clone generating an incomplete, unusable .git/config
- From
Jeff King <peff@peff.net>
- Date
- Nov 12, 2010, 04:41 UTC
- Message-ID
- <20101112044137.GA24915@sigill.intra.peff.net>
- In-Reply-To
- <20101112043229.GB10765@burratino>
On Thu, Nov 11, 2010 at 10:32:30PM -0600, Jonathan Nieder wrote:
Show 26 quoted lines
> 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