> On Wed, Nov 21, 2012 at 10:27:50AM +0100, Krzysztof Mazur wrote:
> > > > * pf/editor-ignore-sigint (2012-11-11) 5 commits
> > > >
> > > > Avoid confusing cases where the user hits Ctrl-C while in the editor
> > > > session, not realizing git will receive the signal. Since most
> > > editors
> > > > will take over the terminal and will block SIGINT, this is not likely
> > > > to confuse anyone.
> > > >
> > > > Some people raised issues with emacsclient, which are addressed by
> > > this
> > > > re-roll. It should probably also handle SIGQUIT, and there were a
> > > > handful of other review comments.
> > > >
> > > > Anybody interested in moving this forward?
> > >
> > > i started this, but then jeff took it and ran with it and made it
> > > right. i think the remaining changes are small -- if jeff would
> > > prefer, i can probably finish it. (but i won't guarantee not to
> > > mess up the "From:" lines. :-)
> > >
> > I'm also interested. I sometimes use ":r !command" in vim, so far I never
> > needed to use Ctrl-C, but maybe in future.
> > The SIGINT part seems to be finished, we need to decide what about SIGQUIT.
> My plan was to just add in SIGQUIT alongside SIGINT (and I think
> there may have been one or two other minor comments in response to the
> series). I am on vacation this week, but can revisit it next week. If
> somebody wants to re-roll it in the meantime, that would be fine with
>  Given the core-dumping behavior of SIGQUIT, I suspect it is not
> nearly as widely used as SIGINT, but it sounds more like the
> principle of least surprise to treat them the same.
i see no real point in treating them the same -- as you suggest, one
would only use SIGQUIT if SIGINT didn't work, and then you'd want them
to be treated differently. so i'd be happy with the current code in
i think krzysiek said that since editors usually catch SIGQUIT, git
should kill the editor when receiving SIGQUIT, essentially translating
the SIGQUIT to SIGTERM for the editor. (please correct me if i
misunderstood.) since well-behaved editors will die quickly anyway
(they get EIO on their next read from stdin), i'm not sure there's a
compelling reason for that extra step.
but i have no real objection to that behavior if others think it's
right -- there's certainly logic in saying that if git dies it should
ensure the editor does too.
(i'm away for the rest of the week also.)
paul fox, p...@foxharp.boston.ma.us (arlington, ma, where it's 44.6 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