Re: [RFC/PATCH 0/5] stop installing old libexec aliases like "git-init"

> On Fri, Nov 16, 2018 at 08:22:11PM +0100, Ævar Arnfjörð Bjarmason wrote:
> 
> > So maybe we should just document this interface better. It seems one
> > implicit dependency is that we expect a manpage for the tool to exist
> > for --help.
> 
> Yeah, I think this really the only problematic assumption. The rest of
> "-c", "--git-dir", etc, are just manipulating the environment, and that
> gets passed through to sub-invocations of Git (so if I have a script
> which calls git-config, it will pick up the "-c" config).
> 
> It would be nice if there was a way to ask "is there a manpage?", and
> fallback to running "git-cmd --help". But:
> 
>   1. I don't think there is a portable way to query that via man. And
>      anyway, depending platform and config, it may be opening a browser
>      to show HTML documentation (or I think even texinfo?).
> 
>   2. We can just ask whether "man git-sizer" (or whatever help display
>      command) returned a non-zero exit code, and fall back to "git-sizer
>      --help". But there's an infinite-loop possibility here: running
>      "git-sizer --help" does what we want. But if "man git-log" failed,
>      we'd run "git-log --help", which in turn runs "git help log", which
>      runs "man git-log", and so on.
> 
>      You can break that loop with an environment variable for "I already
>      tried to show the manpage", which would I guess convert "--help" to
>      "-h".
> 
> So it's maybe do-able, but not quite as trivial as one might hope.

> > But I don't remember the details, and can't reproduce it now with:
> > 
> >     $ cat ~/bin/git-sigint 
> >     #!/usr/bin/env perl
> >     $SIG{INT} = sub { warn localtime . " " . $$ };
> >     sleep 1 while 1;
> >     $ git sigint # or git-sigint
> >     [... behaves the same either way ...]
> > 
> > So maybe it was something else, or I'm misremembering...
> 
> I think that generally works because hitting ^C is going to send SIGINT
> to the whole process group. A more interesting case is:
> 
>   git sigint &
>   kill -INT $!
> 
> There $! is a parent "git" process that is just waiting on git-sigint to
> die. But that works, too, because the parent relays common signals due
> to 10c6cddd92 (dashed externals: kill children on exit, 2012-01-08). So
> you might have been remembering issues prior to that commit (or uncommon
> signals; these come from sigchain_push_common).