On Sun, Nov 11, 2012 at 10:48:46AM -0500, Jeff King wrote: > Silly me. When I thought through the impact of Paul's patch, I knew that > we would notice signal death of the editor. But I totally forgot to > consider that the blocked signal is inherited by the child process. I > think we just need to move the signal() call to after we've forked. Like > this (on top of Paul's patch): > [...] > Note that this will give you a slightly verbose message from git. > Potentially we could notice editor death due to SIGINT and suppress the > message, under the assumption that the user hit ^C and does not need to > be told.
Here's a series that I think should resolve the situation for everybody. [1/5]: launch_editor: refactor to use start/finish_command The cleanup I sent out a few minutes ago. [2/5]: launch_editor: ignore SIGINT while the editor has control Paul's patch rebased on my 1/5. [3/5]: run-command: drop silent_exec_failure arg from wait_or_whine [4/5]: run-command: do not warn about child death by SIGINT [5/5]: launch_editor: propagate SIGINT from editor to git Act more like current git when the editor dies from SIGINT. -Peff -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
