On Fri, Jan 06, 2017 at 11:42:25PM +0100, Johannes Sixt wrote: > > So I dunno. Maybe this waiting should be restricted only to certain > > cases like executing git sub-commands. > > If given it some thought. > > 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. -Peff