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
