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

[Johannes Schindelin <Johannes.Schindelin@gmx.de>]

[-- Attachment #1: Type: text/plain, Size: 3352 bytes --]

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