Jeff King <peff@xxxxxxxx> 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 majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html