Jeff King <> 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.
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to
More majordomo info at

Reply via email to