jeff wrote:
 > 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.

thanks!  i've tested -- this certainly scratches my initial itch.

ack,
paul

 > 
 >   [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

=---------------------
 paul fox, p...@foxharp.boston.ma.us (arlington, ma, where it's 56.3 degrees)
--
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

Reply via email to