* 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 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-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-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).