Hi Peff,
On Sat, 17 Nov 2018, Jeff King wrote:
> 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.
A trivial alternative would be to recommend adding a man page for
3rd-party git-<tool>s.
In other words, as soon as `git-sizer` is accompanied by `git-sizer.1` in
one of the appropriate locations, it is set.
(Actually, it is not: on Windows, it would have to add git-sizer.html in
the appropriate location, but we can deal with this if needed.)
> > 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).
FWIW I do have a couple of scripts I use that I install into
`$HOME/bin/git-<tool>`. Although, granted, I essentially switched to
aliases for most of them, where the aliases still call a script that is
checked out in some folder in my home directory. The reason: this works in
more circumstances, as I do not have to add `$HOME/bin` to the `PATH`,
say, in PowerShell.
So YMMV with git-<tool>s. My rule of thumb is: if I want to use this
myself only, I'll make it an alias. If I want to ship it (e.g. with Git
for Windows), I'll make it a git-<tool>.
Ciao,
Dscho
