Re: [PATCH 0/5] ignore SIGINT while editor runs
- From
Paul Fox <pgf@foxharp.boston.ma.us>
- Date
- Nov 11, 2012, 18:27 UTC
- Message-ID
- <20121111182703.167E92E8B6A@grass.foxharp.boston.ma.us>
- In-Reply-To
- <20121111163100.GB13188@sigill.intra.peff.net>
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 majordomo@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html
=--------------------- paul fox, pgf@foxharp.boston.ma.us (arlington, ma, where it's 56.3 degrees)