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

[Jeff King <peff@peff.net>]

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

-Peff