* Support 'help' for custom/alias commands
[not found] <VI1P192MB025548BB0508125DF9B5852DC81C0@VI1P192MB0255.EURP192.PROD.OUTLOOK.COM>
@ 2020-02-07 10:42 ` paul
2020-02-07 11:29 ` Konstantin Khomoutov
2020-02-07 23:46 ` brian m. carlson
0 siblings, 2 replies; 6+ messages in thread
From: paul @ 2020-02-07 10:42 UTC (permalink / raw)
To: git
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?
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: Support 'help' for custom/alias commands
2020-02-07 10:42 ` Support 'help' for custom/alias commands paul
@ 2020-02-07 11:29 ` Konstantin Khomoutov
2020-02-09 13:16 ` paul
2020-02-07 23:46 ` brian m. carlson
1 sibling, 1 reply; 6+ messages in thread
From: Konstantin Khomoutov @ 2020-02-07 11:29 UTC (permalink / raw)
To: paul; +Cc: git
On Fri, Feb 07, 2020 at 10:42:56AM -0000, paul@pauldsmith.org.uk wrote:
[...]
> 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?
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?
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: Support 'help' for custom/alias commands
2020-02-07 10:42 ` Support 'help' for custom/alias commands paul
2020-02-07 11:29 ` Konstantin Khomoutov
@ 2020-02-07 23:46 ` brian m. carlson
2020-02-09 13:14 ` paul
1 sibling, 1 reply; 6+ messages in thread
From: brian m. carlson @ 2020-02-07 23:46 UTC (permalink / raw)
To: paul; +Cc: git
[-- Attachment #1: Type: text/plain, Size: 2510 bytes --]
On 2020-02-07 at 10:42:56, paul@pauldsmith.org.uk wrote:
> 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.
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.
> 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.
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 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”
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
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 868 bytes --]
^ permalink raw reply [flat|nested] 6+ messages in thread
* RE: Support 'help' for custom/alias commands
2020-02-07 23:46 ` brian m. carlson
@ 2020-02-09 13:14 ` paul
2020-02-09 16:38 ` brian m. carlson
0 siblings, 1 reply; 6+ messages in thread
From: paul @ 2020-02-09 13:14 UTC (permalink / raw)
To: 'brian m. carlson', paul; +Cc: git
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:
> 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.
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.
> 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.
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 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”
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
^ permalink raw reply [flat|nested] 6+ messages in thread
* RE: Support 'help' for custom/alias commands
2020-02-07 11:29 ` Konstantin Khomoutov
@ 2020-02-09 13:16 ` paul
0 siblings, 0 replies; 6+ messages in thread
From: paul @ 2020-02-09 13:16 UTC (permalink / raw)
To: 'Konstantin Khomoutov', paul; +Cc: git
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:
[...]
> 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?
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?
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: Support 'help' for custom/alias commands
2020-02-09 13:14 ` paul
@ 2020-02-09 16:38 ` brian m. carlson
0 siblings, 0 replies; 6+ messages in thread
From: brian m. carlson @ 2020-02-09 16:38 UTC (permalink / raw)
To: paul; +Cc: git
[-- Attachment #1: Type: text/plain, Size: 1258 bytes --]
On 2020-02-09 at 13:14:42, paul@pauldsmith.org.uk wrote:
> 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.
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.
--
brian m. carlson: Houston, Texas, US
OpenPGP: https://keybase.io/bk2204
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 868 bytes --]
^ permalink raw reply [flat|nested] 6+ messages in thread
end of thread, other threads:[~2020-02-09 16:39 UTC | newest]
Thread overview: 6+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
[not found] <VI1P192MB025548BB0508125DF9B5852DC81C0@VI1P192MB0255.EURP192.PROD.OUTLOOK.COM>
2020-02-07 10:42 ` Support 'help' for custom/alias commands paul
2020-02-07 11:29 ` Konstantin Khomoutov
2020-02-09 13:16 ` paul
2020-02-07 23:46 ` brian m. carlson
2020-02-09 13:14 ` paul
2020-02-09 16:38 ` brian m. carlson
Code repositories for project(s) associated with this public inbox
https://80x24.org/mirrors/git.git
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).