On Fri, Jan 6, 2017 at 5:14 PM, Jeff King <p...@peff.net> wrote: > On Fri, Jan 06, 2017 at 06:20:42PM -0500, Jeff King wrote: > >> > In general, I think it is wrong to wait for child processes when a signal >> > was received. After all, it is the purpose of a (deadly) signal to have the >> > process go away. There may be programs that know it better, like less, but >> > git should not attempt to know better in general. >> > >> > We do apply some special behavior for certain cases like we do for the >> > pager. And now the case with aliases is another special situation. The >> > parent git process only delegates to the child, and as such it is >> > reasonable >> > that it binds its life time to the first child, which executes the expanded >> > alias. >> >> Yeah, I think I agree. That binding is something you want in many cases, >> but not necessarily all. The original purpose of clean_on_exit was to >> create a binding like that, but of course it can be (and with the >> smudge-filter stuff, arguably has been) used for other cases, too. >> >> I'll work up a patch that makes it a separate option, which should be >> pretty easy. > > Yeah, this did turn out to be really easy. I spent most of the time > trying to explain the issue in the commit message in a sane way. > Hopefully it didn't end up _too_ long. :) > > The interesting bit is in the third one. The first is a necessary > preparatory step, and the second is a cleanup I noticed in the > neighborhood. > > [1/3]: execv_dashed_external: use child_process struct > [2/3]: execv_dashed_external: stop exiting with negative code > [3/3]: execv_dashed_external: wait for child on signal death > > git.c | 36 +++++++++++++++--------------------- > run-command.c | 19 +++++++++++++++++++ > run-command.h | 1 + > 3 files changed, 35 insertions(+), 21 deletions(-) > > -Peff
I don't see the rest of the patches on the list..? Thanks, Jake
