Re: Custom subcommand help handlers

[Philip Oakley <philipoakley@iee.email>]

On 22/12/2021 19:53, Junio C Hamano wrote:
> Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
>
>> On Mon, 20 Dec 2021, Junio C Hamano wrote:
>>
>>> "brian m. carlson" <sandals@crustytoothpaste.net> writes:
>>>
>>>> I should point out that in most cases on Unix, it _is_ expected that you
>>>> install your manual pages into the same place as everyone else, so in
>>>> this case, installing the HTML documentation alongside Git's may be the
>>>> best solution.
>>> Yup, that sounds like the most sensible way to do things.
>> So what about `~/bin/git-my-reply-to-junio`? Do we expect people to write
>> a manual page and install it into `~/man/man1` and for `man` to pick that
>> up?
> Yes, if they write one, and then tell man that you have extra
> manpages there via MANPATH.
>
> I expect people *not* to write a manual page in practice for such a
> thing, though ;-)

In the very original use case reported in the git for windows issues
pages, I understood it that the provider of the git-foo script expected
that they would include some detection and response to the --help being
given as an option.

They had the issue that their windows users, using Git for Windows, do
not have the `man` package installed. Rather the `web` help of using the
.html version of the man page is used (needs administrator install in
some case). So user commands would need to provide both the man page for
Linux systems and some process to get the html equivalent into the right
folder - this latter case was the problem step. 

The expectation from the XY-Problem was that if the html (and possibly,
by implication, the man page) was not found by git, that the --help
option would be passed to the command itself for it the command to
process (or ignore)..

It is a bit of a rabbit hole.

Philip