Support 'help' for custom/alias commands

Adding a custom comment (let’s call is ‘foolish’) is easy but then you someone types ‘git help foolish’, they get some strange message about help not being found.

There are two problems with this:

1. It’s hard for users to create good documentation in the same format as
the core git product 2. The git ‘help’ processing currently looks in one,
and one place only and that location is often ‘locked down’ meaning that
mere users cannot add their custom help to this directory.

I propose that #1 be solved by creating a command/tool and documentation that explains how to mimic the input to the standard Git help files and have them processed to create the HTML/HTML5/MAN help normally produced.  Ideally it would do exactly the same processing as the core tools (perhaps even having their docs built using this tool now) and use exactly the same template files that core git uses.

I propose that #2 be solved by allowing a new set of ‘git config’ fields. The layout should be sensible and should users to be able to set a git variable which then means that the core git help finds their help text. Possible we want to force

<where I installed my tool>/docs/man, or html, or html5

And the git config variable be something like “help.custom.foolish=<where-foolish-is-installed>/docs”

Paul DS.

P.S. I have a perfectly respectable e-mail address at paul_d_smith@hotmail.com which I have used for years - why won't you accept e-mails from it?

On Fri, Feb 07, 2020 at 10:42:56AM -0000, paul@pauldsmith.org.uk wrote:

[...]

The filters at vger.kernel.org do not allow mails which contain text/html parts (mails which contain _only_ them are surely dropped; not sure about mails with multipart/alternative, which do contain a text/plain counterpart). Was this the case?

Possibly. I use Outlook as my mail client and did select "Plain Text" for both e-mail attempts. The error message implied it was the sending e-mail address (paul_d_smith@hotmail.com) that it didn't like, not the e-mail itself.

Regards, Paul DS.

-----Original Message-----
From: Konstantin Khomoutov <kostix@bswap.ru> 
Sent: 07 February 2020 11:30
To: paul@pauldsmith.org.uk
Cc: git@vger.kernel.org
Subject: Re: Support 'help' for custom/alias commands

On Fri, Feb 07, 2020 at 10:42:56AM -0000, paul@pauldsmith.org.uk wrote:

[...]

The filters at vger.kernel.org do not allow mails which contain text/html parts (mails which contain _only_ them are surely dropped; not sure about mails with multipart/alternative, which do contain a text/plain counterpart). Was this the case?

On 2020-02-07 at 10:42:56, paul@pauldsmith.org.uk wrote:

It is possible to extend the set of locations that one can use for man by setting MANPATH. If you do so, something like "git foolish --help" does indeed work.

There is such a tool, and it's called Asciidoctor. However, it's written in Ruby, and not all users will want to install Ruby as part of their Git installation. It does work nicely, though, and I use it for my own custom Git subcommands.

Also, if a user prefers to use a different tool for creating manual pages or HTML documentation, they can certainly do so.

I think specifying a single location may be a problem because different types of documentation live in different locations. On Debian, man pages live in /usr/share/man, but HTML documentation lives in /usr/share/doc.

We could theoretically add support for this if we did help.foolish.man and help.foolish.html, though.

I don't feel strongly enough about this to implement it, but if you're interested, I could review a patch.

Brian,

Thanks for considering this.  I've not tried MANPATH but will take a look - my employers use both Linux and Windows so this would only address half the issue but I also understand your comments on "one config to rule them all" and the HTML/MAN issue.

I've used ASCIIDOCTOR already to create config but I feel it would be nice if that could be rolled up into some sort of bundle but it users don't want Ruby then yes, it's not going to work for them.  My personal take is that anyone wanting docs for their custom applications should create them like core Git does - and with Docker and similar it's easy to isolate an environment so perhaps a Docker image might be the way to go.

Clearly room for a little more thought on my part.

Regards, Paul DS

-----Original Message-----
From: brian m. carlson <sandals@crustytoothpaste.net> 
Sent: 07 February 2020 23:46
To: paul@pauldsmith.org.uk
Cc: git@vger.kernel.org
Subject: Re: Support 'help' for custom/alias commands

On 2020-02-07 at 10:42:56, paul@pauldsmith.org.uk wrote:

It is possible to extend the set of locations that one can use for man by setting MANPATH. If you do so, something like "git foolish --help" does indeed work.

There is such a tool, and it's called Asciidoctor.  However, it's written in Ruby, and not all users will want to install Ruby as part of their Git installation.  It does work nicely, though, and I use it for my own custom Git subcommands.

Also, if a user prefers to use a different tool for creating manual pages or HTML documentation, they can certainly do so.

I think specifying a single location may be a problem because different types of documentation live in different locations.  On Debian, man pages live in /usr/share/man, but HTML documentation lives in /usr/share/doc.

We could theoretically add support for this if we did help.foolish.man and help.foolish.html, though.

I don't feel strongly enough about this to implement it, but if you're interested, I could review a patch.
--
brian m. carlson: Houston, Texas, US
OpenPGP: https://keybase.io/bk2204

On 2020-02-09 at 13:14:42, paul@pauldsmith.org.uk wrote:

I don't see a problem with us shipping the stylesheets and tooling we use for our conversions as something people can use, and then if they want to install AsciiDoc or Asciidoctor, they can use the same scripts. That wouldn't be that hard to do.

Personally, though, I find that I don't benefit from them much when I write documentation, and so I don't use them. Other people may feel differently, though.