Re: Regression: Ctrl-c from the pager in an alias exits it

From: Jeff King <peff@peff.net>
Date: Jan 6, 2017, 23:20 UTC
Message-ID: <20170106232042.ptn6grtll5wpxhc4@sigill.intra.peff.net>
In-Reply-To: <2ed6f78b-7704-c724-c99b-e310c383c4e8@kdbg.org>

On Fri, Jan 06, 2017 at 11:42:25PM +0100, Johannes Sixt wrote:

Show 15 quoted lines

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