Re: Custom subcommand help handlers

From: Philip Oakley <philipoakley@iee.email>
Date: Dec 23, 2021, 15:07 UTC
Message-ID: <032aced5-4c50-76f7-9ab6-580ffa5775a5@iee.email>
In-Reply-To: <xmqqczloju0q.fsf@gitster.g>

On 22/12/2021 19:53, Junio C Hamano wrote:

Show 19 quoted lines

> 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