From: Junio C Hamano <gitster@pobox.com>
Date: Sun, 02 Dec 2012 10:04:43 GMT
Subject: Re: [PATCH 0/5] ignore SIG{INT,QUIT} when launching editor
Message-ID: <7vboeclqh0.fsf@alter.siamese.dyndns.org>
In-Reply-To: <20121130223943.GA27120@sigill.intra.peff.net>

Jeff King <peff@peff.net> writes:

> Since this can be thought of as "act more like system(3)", I wondered
> whether the signal-ignore logic should be moved into run-command, or
> even used by default for blocking calls to run_command (which are
> basically our version of system(3)). But it is detrimental in the common
> case that the child is not taking control of the terminal, and is just
> an implementation detail (e.g., we call "git update-ref" behind the
> scenes, but the user does not know or care). If they hit ^C during such
> a run and we are ignoring SIGINT, then either:
>
>   1. we will notice the child died by signal and report an
>      error in the subprocess rather than just dying; the end result is
>      similar, but the error is unnecessarily confusing
>
>   2. we do not bother to check the child's return code (because we do
>      not care whether the child succeeded or not, like a "gc --auto");
>      we end up totally ignoring the user's request to abort the
>      operation
>
> So I do not think we care about this behavior except for launching the
> editor. And the signal-propagation behavior of 5/5 is really so weirdly
> editor-specific (because it is about behaving well whether the child
> blocks signals or not).

Nicely explained.  Very much appreciated.