{"thread":{"id":"15117","subject":"Suggestion: \"man git clone\"","startedAt":"2008-08-21T00:11:08Z","lastAt":"2009-07-06T04:11:18Z","messageCount":29,"participants":["H. Peter Anvin","Peter Valdemar Mørch (Lists)","Avery Pennarun","Jeff King","Bert Wesarg","Federico Lucifredi","Miklos Vajna","Michael J Gruber","A Large Angry SCM","Derek Fawcus","Mikael Magnusson","Matthieu Moy","Colin Watson"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"87907","messageId":"48ACB29C.7000606@zytor.com","threadId":"15117","inReplyTo":null,"subject":"Suggestion: \"man git clone\"","fromName":"H. Peter Anvin","fromEmail":"hpa@zytor.com","sentAt":"2008-08-21T00:11:08Z","receivedAt":"2008-08-21T00:11:08Z","isPatch":false,"sender":{"key":"hpa@zytor.com","avatar":null},"body":"Given the recent change of \"git-foo\" to \"git foo\", it would be really \nnice if one could type, for example:\n\n\tman git clone\n\nand actually get the man page for the git clone command.  There are \nquite a few other pieces of software which also could benefit from that \nkind of indirection.\n\nRight now the above command shows the man page git(1) followed by \nclone(2), which I believe has be classified as utterly useless behaviour...\n\n\t-hpa\n"},{"id":"87909","messageId":"48ACB5F4.3000905@sneakemail.com","threadId":"15117","inReplyTo":"48ACB29C.7000606@zytor.com","subject":"Re: Suggestion: \"man git clone\"","fromName":"Peter Valdemar Mørch (Lists)","fromEmail":"4ux6as402@sneakemail.com","sentAt":"2008-08-21T00:25:24Z","receivedAt":"2008-08-21T00:25:24Z","isPatch":false,"sender":{"key":"4ux6as402@sneakemail.com","avatar":null},"body":"H. Peter Anvin hpa-at-zytor.com |Lists| wrote:\n> Given the recent change of \"git-foo\" to \"git foo\", it would be really \n> nice if one could type, for example:\n> \n>     man git clone\n\nSorry man that behaviour is the way \"man\" works. See \"man man\".\n\n   $ git clone --help\nor\n   $ git help clone\n\nwork right?\n\nPeter\n\nP.S: man, there are puns in that...\n-- \nPeter Valdemar Mørch\nhttp://www.morch.com\n"},{"id":"88005","messageId":"48AD99DF.5090802@zytor.com","threadId":"15117","inReplyTo":"48ACB5F4.3000905@sneakemail.com","subject":"Re: Suggestion: \"man git clone\"","fromName":"H. Peter Anvin","fromEmail":"hpa@zytor.com","sentAt":"2008-08-21T16:37:51Z","receivedAt":"2008-08-21T16:37:51Z","isPatch":false,"sender":{"key":"hpa@zytor.com","avatar":null},"body":"Peter Valdemar Mørch (Lists) wrote:\n> \n> Sorry man that behaviour is the way \"man\" works. See \"man man\".\n> \n>   $ git clone --help\n> or\n>   $ git help clone\n> \n> work right?\n> \n> Peter\n> \n> P.S: man, there are puns in that...\n\nI know that that is the way \"man\" currently works.\n\nI doubt you find *anyone* who relies on the current behaviour, so I am \nsuggesting changing man.  That's why the man author was on the recipient \nlist, but you removed it.\n\n\t-hpa\n"},{"id":"88009","messageId":"32541b130808211007xf295e40l567ecf785a8fca22@mail.gmail.com","threadId":"15117","inReplyTo":"48AD99DF.5090802@zytor.com","subject":"Re: Suggestion: \"man git clone\"","fromName":"Avery Pennarun","fromEmail":"apenwarr@gmail.com","sentAt":"2008-08-21T17:07:14Z","receivedAt":"2008-08-21T17:07:14Z","isPatch":false,"sender":{"key":"apenwarr@gmail.com","avatar":"https://avatars.githubusercontent.com/u/20592?v=4"},"body":"On Thu, Aug 21, 2008 at 12:37 PM, H. Peter Anvin <hpa@zytor.com> wrote:\n> man git clone\n>\n> [...]\n>\n> I doubt you find *anyone* who relies on the current behaviour, so I am\n> suggesting changing man.  That's why the man author was on the recipient\n> list, but you removed it.\n>\n\n[and I put him back...]\n\nUnfortunately what we don't have is a proposal that would work better.\n Also, changing the behaviour of 'man' wouldn't work on any platform\nother than Linux (presumably), which means the git documentation\nwouldn't be able to rely on that behaviour.\n\nStill, in a perfect world, what *should* man do in such a case?\nAutomatically open /usr/man/man1/git/clone.1?\n\nThanks,\n\nAvery\n"},{"id":"88010","messageId":"48ADA467.1030407@zytor.com","threadId":"15117","inReplyTo":"32541b130808211007xf295e40l567ecf785a8fca22@mail.gmail.com","subject":"Re: Suggestion: \"man git clone\"","fromName":"H. Peter Anvin","fromEmail":"hpa@zytor.com","sentAt":"2008-08-21T17:22:47Z","receivedAt":"2008-08-21T17:22:47Z","isPatch":false,"sender":{"key":"hpa@zytor.com","avatar":null},"body":"Avery Pennarun wrote:\n> \n> [and I put him back...]\n> \n> Unfortunately what we don't have is a proposal that would work better.\n>  Also, changing the behaviour of 'man' wouldn't work on any platform\n> other than Linux (presumably), which means the git documentation\n> wouldn't be able to rely on that behaviour.\n> \n> Still, in a perfect world, what *should* man do in such a case?\n> Automatically open /usr/man/man1/git/clone.1?\n> \n\nThat would probably be the best option, other options are \n$MANPATH/man1/git\\ clone.1 or $MANPATH/mangit/clone.git (I actually \ntried that on the assumption that it might treat \"git\" as a section; \nunfortunately, it didn't work.)\n\n\t-hpa\n"},{"id":"88012","messageId":"20080821173842.GB26920@coredump.intra.peff.net","threadId":"15117","inReplyTo":"48ADA467.1030407@zytor.com","subject":"Re: Suggestion: \"man git clone\"","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2008-08-21T17:38:42Z","receivedAt":"2008-08-21T17:38:42Z","isPatch":false,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Thu, Aug 21, 2008 at 10:22:47AM -0700, H. Peter Anvin wrote:\n\n> That would probably be the best option, other options are  \n> $MANPATH/man1/git\\ clone.1 or $MANPATH/mangit/clone.git (I actually tried \n> that on the assumption that it might treat \"git\" as a section;  \n> unfortunately, it didn't work.)\n\nThere is some configuration magic about what is a section. Try\n\n  perl -pi -e 's/^SECTION.*/$& git/' /etc/manpath.config\n\nThat seems to convince my man to look in .../mangit, but I'm having\ntrouble actually getting it to find a page and I don't have time to\ninvestigate further now.\n\n-Peff\n"},{"id":"88015","messageId":"36ca99e90808211052k5a67b7ccv7031c38d28f75f73@mail.gmail.com","threadId":"15117","inReplyTo":"48ADA467.1030407@zytor.com","subject":"Re: Suggestion: \"man git clone\"","fromName":"Bert Wesarg","fromEmail":"bert.wesarg@googlemail.com","sentAt":"2008-08-21T17:52:15Z","receivedAt":"2008-08-21T17:52:15Z","isPatch":false,"sender":{"key":"bert.wesarg@googlemail.com","avatar":"https://avatars.githubusercontent.com/u/111934?v=4"},"body":"On Thu, Aug 21, 2008 at 19:22, H. Peter Anvin <hpa@zytor.com> wrote:\n> Avery Pennarun wrote:\n>>\n>> [and I put him back...]\n>>\n>> Unfortunately what we don't have is a proposal that would work better.\n>>  Also, changing the behaviour of 'man' wouldn't work on any platform\n>> other than Linux (presumably), which means the git documentation\n>> wouldn't be able to rely on that behaviour.\n>>\n>> Still, in a perfect world, what *should* man do in such a case?\n>> Automatically open /usr/man/man1/git/clone.1?\n>>\n>\n> That would probably be the best option, other options are $MANPATH/man1/git\\\n> clone.1 or $MANPATH/mangit/clone.git (I actually tried that on the\n> assumption that it might treat \"git\" as a section; unfortunately, it didn't\n> work.)\nIt works here. I have to add 'git' to the SECTION list in /etc/manpath.config.\n\nBert\n>\n>        -hpa\n"},{"id":"88027","messageId":"20080821201307.GC27705@coredump.intra.peff.net","threadId":"15117","inReplyTo":"20080821173842.GB26920@coredump.intra.peff.net","subject":"Re: Suggestion: \"man git clone\"","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2008-08-21T20:13:07Z","receivedAt":"2008-08-21T20:13:07Z","isPatch":false,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Thu, Aug 21, 2008 at 01:38:42PM -0400, Jeff King wrote:\n\n> There is some configuration magic about what is a section. Try\n> \n>   perl -pi -e 's/^SECTION.*/$& git/' /etc/manpath.config\n> \n> That seems to convince my man to look in .../mangit, but I'm having\n> trouble actually getting it to find a page and I don't have time to\n> investigate further now.\n\nAh, OK. My problem was that the pages actually need to be named \"am.git\",\netc. But with 'git' in the section field, \"man git am\" does work.\nUnfortunately, it seems to break \"man git\". :(\n\n-Peff\n"},{"id":"88030","messageId":"48ADCCB1.6040803@zytor.com","threadId":"15117","inReplyTo":"20080821201307.GC27705@coredump.intra.peff.net","subject":"Re: Suggestion: \"man git clone\"","fromName":"H. Peter Anvin","fromEmail":"hpa@zytor.com","sentAt":"2008-08-21T20:14:41Z","receivedAt":"2008-08-21T20:14:41Z","isPatch":false,"sender":{"key":"hpa@zytor.com","avatar":null},"body":"Jeff King wrote:\n> On Thu, Aug 21, 2008 at 01:38:42PM -0400, Jeff King wrote:\n> \n>> There is some configuration magic about what is a section. Try\n>>\n>>   perl -pi -e 's/^SECTION.*/$& git/' /etc/manpath.config\n>>\n>> That seems to convince my man to look in .../mangit, but I'm having\n>> trouble actually getting it to find a page and I don't have time to\n>> investigate further now.\n> \n> Ah, OK. My problem was that the pages actually need to be named \"am.git\",\n> etc. But with 'git' in the section field, \"man git am\" does work.\n> Unfortunately, it seems to break \"man git\". :(\n> \n> -Peff\n\nYeah, that pretty much makes it not a general solution.\n\n\t-hpa\n"},{"id":"88032","messageId":"20080821201828.GA28844@coredump.intra.peff.net","threadId":"15117","inReplyTo":"48ADCCB1.6040803@zytor.com","subject":"Re: Suggestion: \"man git clone\"","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2008-08-21T20:18:28Z","receivedAt":"2008-08-21T20:18:28Z","isPatch":false,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Thu, Aug 21, 2008 at 01:14:41PM -0700, H. Peter Anvin wrote:\n\n>> Ah, OK. My problem was that the pages actually need to be named \"am.git\",\n>> etc. But with 'git' in the section field, \"man git am\" does work.\n>> Unfortunately, it seems to break \"man git\". :(\n>\n> Yeah, that pretty much makes it not a general solution.\n\nOh, sorry, this was just me being incompetent. I was testing with\n\n  MANSECT=git man git am\n\nand of course\n\n  MANSECT=git man git\n\nbroke because we are no longer looking in section \"1\".\n\nSetting the sections properly (by adding \"git\" to /etc/manpath.config,\nor using MANSECT=1:git) and creating a linkfarm in .../man/mangit (with\nam.git pointing to ../man1/git-am.1) makes both \"man git\" and \"man git\nam\" work fine.\n\nThe changes to manpath.config make it a bit outside the scope of git's\nregular install, but maybe this is something distro people would want to\ndo.\n\n-Peff\n"},{"id":"88049","messageId":"48ADE2FF.4080704@acm.org","threadId":"15117","inReplyTo":"48ACB29C.7000606@zytor.com","subject":"Re: Suggestion: \"man git clone\"","fromName":"Federico Lucifredi","fromEmail":"flucifredi@acm.org","sentAt":"2008-08-21T21:49:51Z","receivedAt":"2008-08-21T21:49:51Z","isPatch":false,"sender":{"key":"flucifredi@acm.org","avatar":"https://gravatar.com/avatar/b79ecef647be321885840be58ccfa3b1051e47b642984f66d2d16d4fd974e4c9?d=mp&s=160"},"body":"Hello HP,\n  I have seen this in (funnily enough) a project I manage myself, which \nhas subcommands structured similarly to Git.\n\n  I have looked at options, but so far the current behavior (man \nfoo-bar) seems the best option for foo's subcommand bar. The \nalternative, also acceptable, is a large page with subsections for each \ncommand. Sections (man 1) are used for chapter-like page groupings, not \nfor subsections on a single command - those would have to be implemented \nas an additional layer.\n\n  But, as another participant in the thread has commented, that would \nnot port to other platforms very quickly (although it would get to Linux \nand OS-X promptly, and may eventually make its way into other platforms).\n\n  I am open to ideas, but so far the two options above are better than \nanything else that has been so far suggested...\n\n  Best -F\n\nH. Peter Anvin wrote:\n> Given the recent change of \"git-foo\" to \"git foo\", it would be really \n> nice if one could type, for example:\n> \n>     man git clone\n> \n> and actually get the man page for the git clone command.  There are \n> quite a few other pieces of software which also could benefit from that \n> kind of indirection.\n> \n> Right now the above command shows the man page git(1) followed by \n> clone(2), which I believe has be classified as utterly useless behaviour...\n> \n>     -hpa\n\n\n-- \n\n_________________________________________\n-- \"'Problem' is a bleak word for challenge\" - Richard Fish\n(Federico L. Lucifredi) - http://www.lucifredi.com\n"},{"id":"88054","messageId":"48ADF542.9010105@zytor.com","threadId":"15117","inReplyTo":"48ADE2FF.4080704@acm.org","subject":"Re: Suggestion: \"man git clone\"","fromName":"H. Peter Anvin","fromEmail":"hpa@zytor.com","sentAt":"2008-08-21T23:07:46Z","receivedAt":"2008-08-21T23:07:46Z","isPatch":false,"sender":{"key":"hpa@zytor.com","avatar":null},"body":"Federico Lucifredi wrote:\n> Hello HP,\n>  I have seen this in (funnily enough) a project I manage myself, which \n> has subcommands structured similarly to Git.\n> \n>  I have looked at options, but so far the current behavior (man foo-bar) \n> seems the best option for foo's subcommand bar. The alternative, also \n> acceptable, is a large page with subsections for each command. Sections \n> (man 1) are used for chapter-like page groupings, not for subsections on \n> a single command - those would have to be implemented as an additional \n> layer.\n> \n>  But, as another participant in the thread has commented, that would not \n> port to other platforms very quickly (although it would get to Linux and \n> OS-X promptly, and may eventually make its way into other platforms).\n> \n>  I am open to ideas, but so far the two options above are better than \n> anything else that has been so far suggested...\n> \n\nOne option would be to support \"man foo bar\" showing the page labelled \nfoo-bar.  That way you'd get at least a modicum of bass-ackwards \ncompatibility.\n\nHowever, at some point we have to be willing to do things other \nplatforms won't, or we'll never do anything new...\n\n\t-hpa\n"},{"id":"88066","messageId":"48AE035C.8000504@acm.org","threadId":"15117","inReplyTo":"48ADF542.9010105@zytor.com","subject":"Re: Suggestion: \"man git clone\"","fromName":"Federico Lucifredi","fromEmail":"flucifredi@acm.org","sentAt":"2008-08-22T00:07:56Z","receivedAt":"2008-08-22T00:07:56Z","isPatch":false,"sender":{"key":"flucifredi@acm.org","avatar":"https://gravatar.com/avatar/b79ecef647be321885840be58ccfa3b1051e47b642984f66d2d16d4fd974e4c9?d=mp&s=160"},"body":"H. Peter Anvin wrote:\n> Federico Lucifredi wrote:\n\n[...]\n\n>>  I am open to ideas, but so far the two options above are better than \n>> anything else that has been so far suggested...\n>>\n> \n> One option would be to support \"man foo bar\" showing the page labelled \n> foo-bar.  That way you'd get at least a modicum of bass-ackwards \n> compatibility.\n\nI am all for bass-ackwards compatibility, and I think the suggestion of \ngoing on \"man foo bar\" :\n\n  1) look for foo-bar; if success, terminate search\n  2) look for foo\n  3) look for bar\n  ....\n\nmay be acceptable - I don't see drawbacks at a first glance, and it \nwould allow for groups of pages to be meaningful.\n\nAre you willing to put your patch where your mouth is? :-)\n\n  Best -F\n> \n> However, at some point we have to be willing to do things other \n> platforms won't, or we'll never do anything new...\n> \n>     -hpa\n\n\n-- \n_________________________________________\n-- \"'Problem' is a bleak word for challenge\" - Richard Fish\n(Federico L. Lucifredi) - flucifredi@acm.org\n"},{"id":"88069","messageId":"20080822004052.GA30476@coredump.intra.peff.net","threadId":"15117","inReplyTo":"48AE035C.8000504@acm.org","subject":"Re: Suggestion: \"man git clone\"","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2008-08-22T00:40:52Z","receivedAt":"2008-08-22T00:40:52Z","isPatch":false,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Thu, Aug 21, 2008 at 08:07:56PM -0400, Federico Lucifredi wrote:\n\n> I am all for bass-ackwards compatibility, and I think the suggestion of  \n> going on \"man foo bar\" :\n>\n>  1) look for foo-bar; if success, terminate search\n>  2) look for foo\n>  3) look for bar\n>  ....\n>\n> may be acceptable - I don't see drawbacks at a first glance, and it would \n> allow for groups of pages to be meaningful.\n\nWell, the drawback is that there exist X-Y such that X and Y both have\nmanpages (e.g., cvs-debc on my debian box). So we are assuming that the\nrisk is acceptably low of somebody asking for \"man X Y\", wanting two\nmanpages, and that X and Y fit this pattern.\n\nPersonally I have never ever wanted to see two manpages from one man\ninvocation, so I have no real problem with that assumption.\n\n> Are you willing to put your patch where your mouth is? :-)\n\nI've never looked at man code before, but there seem to be at least two\nman packages for Linux. My boxes have man-db 2.5.2.\n\n-Peff\n"},{"id":"88070","messageId":"20080822004250.GB30476@coredump.intra.peff.net","threadId":"15117","inReplyTo":"20080822004052.GA30476@coredump.intra.peff.net","subject":"Re: Suggestion: \"man git clone\"","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2008-08-22T00:42:50Z","receivedAt":"2008-08-22T00:42:50Z","isPatch":false,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Thu, Aug 21, 2008 at 08:40:52PM -0400, Jeff King wrote:\n\n> Well, the drawback is that there exist X-Y such that X and Y both have\n> manpages (e.g., cvs-debc on my debian box). So we are assuming that the\n\nRe-reading this, it may not be clear what I meant. I mean there exists a\n_manpage_ \"X-Y\" such that \"X\" and \"Y\" are also manpages. So on my system\nthere are three commands, each with a manpage: cvs, debc, and cvs-debc.\n\n-Peff\n"},{"id":"88072","messageId":"20080822011515.GY23800@genesis.frugalware.org","threadId":"15117","inReplyTo":"20080822004052.GA30476@coredump.intra.peff.net","subject":"Re: Suggestion: \"man git clone\"","fromName":"Miklos Vajna","fromEmail":"vmiklos@frugalware.org","sentAt":"2008-08-22T01:15:15Z","receivedAt":"2008-08-22T01:15:15Z","isPatch":false,"sender":{"key":"vmiklos@frugalware.org","avatar":"https://gravatar.com/avatar/401c1cbbb3a5d13e650c691a2c71d6fd0b80df1a01bc74d9f1972675dd58f2bd?d=mp&s=160"},"body":"On Thu, Aug 21, 2008 at 08:40:52PM -0400, Jeff King <peff@peff.net> wrote:\n> I've never looked at man code before, but there seem to be at least two\n> man packages for Linux. My boxes have man-db 2.5.2.\n\nObviously that's not the one Federico maintains. ;-)\n\nSee http://primates.ximian.com/~flucifredi/man/, it's at 1.6f.\n"},{"id":"88073","messageId":"48AE143C.8030704@acm.org","threadId":"15117","inReplyTo":"20080822004052.GA30476@coredump.intra.peff.net","subject":"Re: Suggestion: \"man git clone\"","fromName":"Federico Lucifredi","fromEmail":"flucifredi@acm.org","sentAt":"2008-08-22T01:19:56Z","receivedAt":"2008-08-22T01:19:56Z","isPatch":false,"sender":{"key":"flucifredi@acm.org","avatar":"https://gravatar.com/avatar/b79ecef647be321885840be58ccfa3b1051e47b642984f66d2d16d4fd974e4c9?d=mp&s=160"},"body":"Jeff King wrote:\n> On Thu, Aug 21, 2008 at 08:07:56PM -0400, Federico Lucifredi wrote:\n> \n>> I am all for bass-ackwards compatibility, and I think the suggestion of  \n>> going on \"man foo bar\" :\n>>\n>>  1) look for foo-bar; if success, terminate search\n>>  2) look for foo\n>>  3) look for bar\n>>  ....\n>>\n>> may be acceptable - I don't see drawbacks at a first glance, and it would \n>> allow for groups of pages to be meaningful.\n> \n> Well, the drawback is that there exist X-Y such that X and Y both have\n> manpages (e.g., cvs-debc on my debian box). So we are assuming that the\n> risk is acceptably low of somebody asking for \"man X Y\", wanting two\n> manpages, and that X and Y fit this pattern.\n> \n\nThat's right.\n\n> Personally I have never ever wanted to see two manpages from one man\n> invocation, so I have no real problem with that assumption.\n> \n\nI expected as much, and we should have an option to disable the \"new\" \nbehavior as a safety anyway.\n\n>> Are you willing to put your patch where your mouth is? :-)\n> \n> I've never looked at man code before, but there seem to be at least two\n> man packages for Linux. My boxes have man-db 2.5.2.\n\nThere are two man packages for linux, man and man-db, the latter being a \n90's fork that uses Berkeley DB as a backend to speedup man -k searches \n(it helped back then).\n\n  Best -F\n-- \n_________________________________________\n-- \"'Problem' is a bleak word for challenge\" - Richard Fish\n(Federico L. Lucifredi) - flucifredi@acm.org\n"},{"id":"88075","messageId":"20080822012112.GA31615@coredump.intra.peff.net","threadId":"15117","inReplyTo":"20080822011515.GY23800@genesis.frugalware.org","subject":"Re: Suggestion: \"man git clone\"","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2008-08-22T01:21:12Z","receivedAt":"2008-08-22T01:21:12Z","isPatch":false,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Fri, Aug 22, 2008 at 03:15:15AM +0200, Miklos Vajna wrote:\n\n> On Thu, Aug 21, 2008 at 08:40:52PM -0400, Jeff King <peff@peff.net> wrote:\n> > I've never looked at man code before, but there seem to be at least two\n> > man packages for Linux. My boxes have man-db 2.5.2.\n> \n> Obviously that's not the one Federico maintains. ;-)\n> \n> See http://primates.ximian.com/~flucifredi/man/, it's at 1.6f.\n\nRight. What I meant was two-fold:\n\n  1. \"I am not going to take your patch challenge, because I don't even\n     seem to be running your man pager.\"\n\n  2. It has been noted in this thread that this will only affect Linux.\n     But it is even worse; it will only affect some distributions. So\n     people need to get several implementations to agree.\n\n-Peff\n"},{"id":"88074","messageId":"48AE1489.9050103@acm.org","threadId":"15117","inReplyTo":"20080822011515.GY23800@genesis.frugalware.org","subject":"Re: Suggestion: \"man git clone\"","fromName":"Federico Lucifredi","fromEmail":"flucifredi@acm.org","sentAt":"2008-08-22T01:21:13Z","receivedAt":"2008-08-22T01:21:13Z","isPatch":false,"sender":{"key":"flucifredi@acm.org","avatar":"https://gravatar.com/avatar/b79ecef647be321885840be58ccfa3b1051e47b642984f66d2d16d4fd974e4c9?d=mp&s=160"},"body":"Miklos Vajna wrote:\n> On Thu, Aug 21, 2008 at 08:40:52PM -0400, Jeff King <peff@peff.net> wrote:\n>> I've never looked at man code before, but there seem to be at least two\n>> man packages for Linux. My boxes have man-db 2.5.2.\n> \n> Obviously that's not the one Federico maintains. ;-)\n> \n> See http://primates.ximian.com/~flucifredi/man/, it's at 1.6f.\n\nIndeed. man-db has a higher numbering than man, which sometimes reduces \nconfusion, and sometimes increases it.\n\n  Best -F\n\n-- \n_________________________________________\n-- \"'Problem' is a bleak word for challenge\" - Richard Fish\n(Federico L. Lucifredi) - flucifredi@acm.org\n"},{"id":"88114","messageId":"g8m6d1$7nf$1@ger.gmane.org","threadId":"15117","inReplyTo":"48ACB29C.7000606@zytor.com","subject":"Re: Suggestion: \"man git clone\"","fromName":"Michael J Gruber","fromEmail":"michaeljgruber+gmane@fastmail.fm","sentAt":"2008-08-22T11:02:57Z","receivedAt":"2008-08-22T11:02:57Z","isPatch":false,"sender":{"key":"git@grubix.eu","avatar":"https://avatars.githubusercontent.com/u/233215?v=4"},"body":"H. Peter Anvin venit, vidit, dixit 21.08.2008 02:11:\n> Given the recent change of \"git-foo\" to \"git foo\", it would be really \n> nice if one could type, for example:\n> \n> \tman git clone\n> \n> and actually get the man page for the git clone command.  There are \n> quite a few other pieces of software which also could benefit from that \n> kind of indirection.\n> \n> Right now the above command shows the man page git(1) followed by \n> clone(2), which I believe has be classified as utterly useless behaviour...\n\nThe discussion seems to show that altering man and relying on the new\nbehaviour is no option, and neither is playing games with man's section\noptions.\n\nHow about:\n\n- Change all references inside git (warnings etc) from \"man git-bla\" to\n\"git help bla\".\n\n- Change all references in the help pages (gitlinks) accordingly.\n\n- Put a warning in the main git man page which redirects the confused\n(\"If you were looking for the manpage of \"git bla\" and issued \"man git\nbla\", please refer to \"man git-bla\" or \"git help bla\".'), maybe just\nbefore the command list there.\n\nThis could be supported by an alias mapping \"git man\" to \"git help -m\".\n\nI've heard about some other SCMs which have only \"scm help bla\", so this\nsuggestion would be in-line with common usage. [Not that git would have\nto learn from other SCM's ;) ]\n\nMichael\n"},{"id":"88115","messageId":"48AEA510.6040004@gmail.com","threadId":"15117","inReplyTo":"48AD99DF.5090802@zytor.com","subject":"Re: Suggestion: \"man git clone\"","fromName":"A Large Angry SCM","fromEmail":"gitzilla@gmail.com","sentAt":"2008-08-22T11:37:52Z","receivedAt":"2008-08-22T11:37:52Z","isPatch":false,"sender":{"key":"gitzilla@gmail.com","avatar":"https://gravatar.com/avatar/354625c442439908ff3dd99757dee330e29e9df7847472384faf7a00add247fb?d=mp&s=160"},"body":"H. Peter Anvin wrote:\n> Peter Valdemar Mørch (Lists) wrote:\n>>\n>> Sorry man that behaviour is the way \"man\" works. See \"man man\".\n>>\n>>   $ git clone --help\n>> or\n>>   $ git help clone\n>>\n>> work right?\n>>\n>> Peter\n>>\n>> P.S: man, there are puns in that...\n> \n> I know that that is the way \"man\" currently works.\n> \n> I doubt you find *anyone* who relies on the current behaviour, so I am \n> suggesting changing man.  That's why the man author was on the recipient \n> list, but you removed it.\n\nActually, the current \"man\" behavior is very convenient when  you want \nto lookup multiple things. And *I* do use that feature.\n"},{"id":"88139","messageId":"20080822150353.GC13490@cisco.com","threadId":"15117","inReplyTo":"g8m6d1$7nf$1@ger.gmane.org","subject":"Re: Suggestion: \"man git clone\"","fromName":"Derek Fawcus","fromEmail":"dfawcus@cisco.com","sentAt":"2008-08-22T15:03:53Z","receivedAt":"2008-08-22T15:03:53Z","isPatch":false,"sender":{"key":"dfawcus@cisco.com","avatar":null},"body":"On Fri, Aug 22, 2008 at 01:02:57PM +0200, Michael J Gruber wrote:\n> I've heard about some other SCMs which have only \"scm help bla\", so this\n> suggestion would be in-line with common usage. [Not that git would have\n> to learn from other SCM's ;) ]\n\nClearcase - commands such as 'cleartool describe',  man page in ct+describe.1\n\nHas 'cleartool help describe' (and 'cleartool describe -help') which gives a\nusage summary,  and 'cleartool man describe' (or 'man ct+describe') for the\nman page.\n\nSo basically the same solution,  but a slightly different choice/use for keywords.\n\n(and if one has an alias 'ct=cleartool',  it seems to make more sense).\n\nDF\n"},{"id":"88146","messageId":"237967ef0808220853k24b2d969l55d04ec13bd7c8c9@mail.gmail.com","threadId":"15117","inReplyTo":"g8m6d1$7nf$1@ger.gmane.org","subject":"Re: Suggestion: \"man git clone\"","fromName":"Mikael Magnusson","fromEmail":"mikachu@gmail.com","sentAt":"2008-08-22T15:53:45Z","receivedAt":"2008-08-22T15:53:45Z","isPatch":false,"sender":{"key":"mikachu@gmail.com","avatar":null},"body":"2008/8/22 Michael J Gruber <michaeljgruber+gmane@fastmail.fm>:\n> H. Peter Anvin venit, vidit, dixit 21.08.2008 02:11:\n>> Given the recent change of \"git-foo\" to \"git foo\", it would be really\n>> nice if one could type, for example:\n>>\n>>       man git clone\n>>\n>> and actually get the man page for the git clone command.  There are\n>> quite a few other pieces of software which also could benefit from that\n>> kind of indirection.\n>>\n>> Right now the above command shows the man page git(1) followed by\n>> clone(2), which I believe has be classified as utterly useless behaviour...\n>\n> The discussion seems to show that altering man and relying on the new\n> behaviour is no option, and neither is playing games with man's section\n> options.\n>\n> How about:\n>\n> - Change all references in the help pages (gitlinks) accordingly.\n\nI think that would break navigating man pages in any man reader... Most of\nthem detect and handle \"foo(N)\" magically and let you click on it.\n\n-- \nMikael Magnusson\n"},{"id":"88448","messageId":"vpqk5e52rrx.fsf@bauges.imag.fr","threadId":"15117","inReplyTo":"g8m6d1$7nf$1@ger.gmane.org","subject":"Re: Suggestion: \"man git clone\"","fromName":"Matthieu Moy","fromEmail":"matthieu.moy@imag.fr","sentAt":"2008-08-25T12:38:58Z","receivedAt":"2008-08-25T12:38:58Z","isPatch":false,"sender":{"key":"git@matthieu-moy.fr","avatar":"https://avatars.githubusercontent.com/u/14709?v=4"},"body":"Michael J Gruber <michaeljgruber+gmane@fastmail.fm> writes:\n\n> I've heard about some other SCMs which have only \"scm help bla\", so this\n> suggestion would be in-line with common usage. [Not that git would have\n> to learn from other SCM's ;) ]\n\nOTOH, I like the fact that the manpages be browsable with man. As an\nEmacs user, I often do M-x man RET git-whatever RET, other people can\nenjoy their favorite man reader.\n\nIf git starts hiding that \"man\" stuff to the user, (s)he may just fail\nto notice that it is possible.\n\n-- \nMatthieu\n"},{"id":"89711","messageId":"48BF4662.9000305@acm.org","threadId":"15117","inReplyTo":"48ADE2FF.4080704@acm.org","subject":"Re: Suggestion: \"man git clone\"","fromName":"Federico Lucifredi","fromEmail":"flucifredi@acm.org","sentAt":"2008-09-04T02:22:26Z","receivedAt":"2008-09-04T02:22:26Z","isPatch":false,"sender":{"key":"flucifredi@acm.org","avatar":"https://gravatar.com/avatar/b79ecef647be321885840be58ccfa3b1051e47b642984f66d2d16d4fd974e4c9?d=mp&s=160"},"body":"Hello HP, All,\n  I somehow managed to forget this (age must be taking its toll), but \nthere is a convention commonly used for man pages of Perl Modules, which \ncan be reasonably usable for subcommands as well:\n\n  man APR::Brigade\n\nwill work just fine, with a file by the same name. This convention is in \ncurrent use, and would map to\n\n  man git::clone\n\nwhile :: is not as immediate in context as in Perl, it does do the job, \nand works regardless of pager.\n\n  I would still go with the single big page (people are used to \nvi-search with \"/\" anyway), but if you want to split the manual this \nwould work, and you could refer to the pages explicitly in the main git \npage.\n\n  Finally, and importantly, \"apropos clone\" or \"man -k clone\" would \ncorrectly point to git::clone as a valid result.\n\n  One more option for you.\n\n  Best -F\n\nFederico Lucifredi wrote:\n> Hello HP,\n>  I have seen this in (funnily enough) a project I manage myself, which \n> has subcommands structured similarly to Git.\n> \n>  I have looked at options, but so far the current behavior (man foo-bar) \n> seems the best option for foo's subcommand bar. The alternative, also \n> acceptable, is a large page with subsections for each command. Sections \n> (man 1) are used for chapter-like page groupings, not for subsections on \n> a single command - those would have to be implemented as an additional \n> layer.\n> \n>  But, as another participant in the thread has commented, that would not \n> port to other platforms very quickly (although it would get to Linux and \n> OS-X promptly, and may eventually make its way into other platforms).\n> \n>  I am open to ideas, but so far the two options above are better than \n> anything else that has been so far suggested...\n> \n>  Best -F\n> \n> H. Peter Anvin wrote:\n>> Given the recent change of \"git-foo\" to \"git foo\", it would be really \n>> nice if one could type, for example:\n>>\n>>     man git clone\n>>\n>> and actually get the man page for the git clone command.  There are \n>> quite a few other pieces of software which also could benefit from \n>> that kind of indirection.\n>>\n>> Right now the above command shows the man page git(1) followed by \n>> clone(2), which I believe has be classified as utterly useless \n>> behaviour...\n>>\n>>     -hpa\n> \n> \n\n\n-- \n_________________________________________\n-- \"'Problem' is a bleak word for challenge\" - Richard Fish\n(Federico L. Lucifredi) - flucifredi@acm.org\n"},{"id":"89716","messageId":"48BF5678.8080201@zytor.com","threadId":"15117","inReplyTo":"48BF4662.9000305@acm.org","subject":"Re: Suggestion: \"man git clone\"","fromName":"H. Peter Anvin","fromEmail":"hpa@zytor.com","sentAt":"2008-09-04T03:31:04Z","receivedAt":"2008-09-04T03:31:04Z","isPatch":false,"sender":{"key":"hpa@zytor.com","avatar":null},"body":"Federico Lucifredi wrote:\n> Hello HP, All,\n>  I somehow managed to forget this (age must be taking its toll), but \n> there is a convention commonly used for man pages of Perl Modules, which \n> can be reasonably usable for subcommands as well:\n> \n>  man APR::Brigade\n> \n> will work just fine, with a file by the same name. This convention is in \n> current use, and would map to\n> \n>  man git::clone\n> \n> while :: is not as immediate in context as in Perl, it does do the job, \n> and works regardless of pager.\n> \n\nThat's just as bad as \"man git-clone\".  Arguably worse.\n\n\t-hpa\n"},{"id":"117113","messageId":"20090628023458.297703BC143@sarantium.pelham.vpn.ucam.org","threadId":"15117","inReplyTo":"48AE143C.8030704@acm.org","subject":"Re: Suggestion: \"man git clone\"","fromName":"Colin Watson","fromEmail":"cjwatson@debian.org","sentAt":"2009-06-28T02:34:57Z","receivedAt":"2009-06-28T02:34:57Z","isPatch":false,"sender":{"key":"cjwatson@debian.org","avatar":null},"body":"(Sorry I didn't see this until now. HPA only CCed the maintainer of one\nof the two man packages popular on Linux-based systems; I'm the other\none. I happened to find this thread while searching for something else.)\n\nIn article <48AE143C.8030704@acm.org>, Federico Lucifredi wrote:\n>Jeff King wrote:\n>> On Thu, Aug 21, 2008 at 08:07:56PM -0400, Federico Lucifredi wrote:\n>>> I am all for bass-ackwards compatibility, and I think the suggestion of  \n>>> going on \"man foo bar\" :\n>>>\n>>>  1) look for foo-bar; if success, terminate search\n>>>  2) look for foo\n>>>  3) look for bar\n>>>  ....\n>>>\n>>> may be acceptable - I don't see drawbacks at a first glance, and it would \n>>> allow for groups of pages to be meaningful.\n\nI think this is a sensible enough compromise, especially given an option\nto disable it. The code would be a little ugly, but *shrug* not that\nbad. The extra stat is cheap enough.\n\nUsing a plain 'git' section for this in order to provoke the\nhappenstance of 'man git clone' working is definitely wrong as far as\nthe manual page hierarchy goes; it means that things like searching for\njust user commands (section 1) that contain some term will fail. Putting\nthem in section '1git' (i.e. section 1 with a git \"extension\") would be\nmore in line with how manual pages are typically laid out, and at least\nwith man-db would not require any configuration file changes. However, I\nthink both of these are suboptimal. Section extensions are typically\nused for things like functions or modules in other programming\nlanguages, or sometimes for cases where file names would otherwise\nclash. I'm not much of a git user myself, but I don't get the impression\nthat most git users think of 'git clone' as analogous to a 'clone'\ncommand in a hypothetical 'git' programming language; it's closer to an\nordinary user command.\n\nThe only case where I've seen subcommands given their own unprefixed\nmanual pages with only the section extension to tell them apart is\nOpenSSL, with pages like x509(1ssl). IME, this is very confusing and not\na good example to follow: firstly, you can't trivially find a list of\nall the subcommands with something like 'apropos openssl-'; secondly,\nit's easy to miss that you're dealing with an openssl subcommand unless\nyou keep your eyes peeled.\n\nShort of some mechanism for git to provide a plug-in to man to tell it\nwhere to find subpages (eek! potential overengineering alert!), a\nfoo-bar lookup seems tolerable enough.\n\n>> Personally I have never ever wanted to see two manpages from one man\n>> invocation, so I have no real problem with that assumption.\n>\n>I expected as much, and we should have an option to disable the \"new\" \n>behavior as a safety anyway.\n\nWould you like to suggest an option name for this, so that we can avoid\nunnecessary divergence? Perhaps something like --separate?\n\n>>> Are you willing to put your patch where your mouth is? :-)\n>> \n>> I've never looked at man code before, but there seem to be at least two\n>> man packages for Linux. My boxes have man-db 2.5.2.\n>\n>There are two man packages for linux, man and man-db, the latter being a \n>90's fork that uses Berkeley DB as a backend to speedup man -k searches \n>(it helped back then).\n\n(I hope git@ will excuse the digression.)\n\nDon't be confused by the name. Once upon a time the main feature of\nman-db was indeed its database; these days that's almost one of the\nleast interesting features as far as I'm concerned (and I recommend GDBM\nfor the database layer nowadays anyway, since Berkeley DB is overkill\nand has gone through an annoying number of disk format changes).\n\nThese days, much more relevant are things like the fact that man-db can\nhandle encodings properly (both in manual pages and its own translated\nmessages; *why* does man still use catgets?), and the effort put into\nprocess glue libraries so that it doesn't have to be audited carefully\nfor unsafe shell code and so that it can be a lot more efficient when\nprocessing large numbers of manual pages (e.g. man -K).\n\nAnyway, if you look at the history, what happened is that John W. Eaton\nwrote the original man way back in 1990/1 or so, then two different sets\nof people developed it in different directions into man and man-db. That\nwas in the early 1990s when free software developers weren't\ncommunicating as often as they do now. Then, by the time it became\nobvious around 1995 that there'd been a fork, the two were already\nseparate packages with different aims and it was now too hard for anyone\nto merge them. You could still see the common ancestry if you looked\nclosely (indeed, you still can in places), but they're really much more\nlike two completely separate implementations than a fork. It's a bit of\na shame in some ways, but harmless enough.\n\nCheers,\n\n-- \nColin Watson                                       [cjwatson@debian.org]\n"},{"id":"117488","messageId":"4A5165F0.8020107@acm.org","threadId":"15117","inReplyTo":"20090628023458.297703BC143@sarantium.pelham.vpn.ucam.org","subject":"Re: Suggestion: \"man git clone\"","fromName":"Federico Lucifredi","fromEmail":"flucifredi@acm.org","sentAt":"2009-07-06T02:48:16Z","receivedAt":"2009-07-06T02:48:16Z","isPatch":false,"sender":{"key":"flucifredi@acm.org","avatar":"https://gravatar.com/avatar/b79ecef647be321885840be58ccfa3b1051e47b642984f66d2d16d4fd974e4c9?d=mp&s=160"},"body":"Colin Watson wrote:\n> (Sorry I didn't see this until now. HPA only CCed the maintainer of one\n> of the two man packages popular on Linux-based systems; I'm the other\n> one. I happened to find this thread while searching for something else.)\n> \n\nReally? Sorry, I thought I had added you. My bad.\n\n> In article <48AE143C.8030704@acm.org>, Federico Lucifredi wrote:\n>> Jeff King wrote:\n>>> On Thu, Aug 21, 2008 at 08:07:56PM -0400, Federico Lucifredi wrote:\n>>>> I am all for bass-ackwards compatibility, and I think the suggestion of  \n>>>> going on \"man foo bar\" :\n>>>>\n>>>>  1) look for foo-bar; if success, terminate search\n>>>>  2) look for foo\n>>>>  3) look for bar\n>>>>  ....\n>>>>\n>>>> may be acceptable - I don't see drawbacks at a first glance, and it would \n>>>> allow for groups of pages to be meaningful.\n> \n> I think this is a sensible enough compromise, especially given an option\n> to disable it. The code would be a little ugly, but *shrug* not that\n> bad. The extra stat is cheap enough.\n> \n\nSounds good to me :)\n\n> Using a plain 'git' section for this in order to provoke the\n> happenstance of 'man git clone' working is definitely wrong as far as\n> the manual page hierarchy goes; it means that things like searching for\n> just user commands (section 1) that contain some term will fail. Putting\n> them in section '1git' (i.e. section 1 with a git \"extension\") would be\n> more in line with how manual pages are typically laid out, and at least\n> with man-db would not require any configuration file changes. However, I\n> think both of these are suboptimal. Section extensions are typically\n> used for things like functions or modules in other programming\n> languages, or sometimes for cases where file names would otherwise\n> clash. I'm not much of a git user myself, but I don't get the impression\n> that most git users think of 'git clone' as analogous to a 'clone'\n> command in a hypothetical 'git' programming language; it's closer to an\n> ordinary user command.\n> \n> The only case where I've seen subcommands given their own unprefixed\n> manual pages with only the section extension to tell them apart is\n> OpenSSL, with pages like x509(1ssl). IME, this is very confusing and not\n> a good example to follow: firstly, you can't trivially find a list of\n> all the subcommands with something like 'apropos openssl-'; secondly,\n> it's easy to miss that you're dealing with an openssl subcommand unless\n> you keep your eyes peeled.\n> \n> Short of some mechanism for git to provide a plug-in to man to tell it\n> where to find subpages (eek! potential overengineering alert!), a\n> foo-bar lookup seems tolerable enough.\n> \n>>> Personally I have never ever wanted to see two manpages from one man\n>>> invocation, so I have no real problem with that assumption.\n>> I expected as much, and we should have an option to disable the \"new\" \n>> behavior as a safety anyway.\n> \n> Would you like to suggest an option name for this, so that we can avoid\n> unnecessary divergence? Perhaps something like --separate?\n\nthe option to trigger \"classic\" behavior? How about --no-subpages?\n\n> \n>>>> Are you willing to put your patch where your mouth is? :-)\n>>> I've never looked at man code before, but there seem to be at least two\n>>> man packages for Linux. My boxes have man-db 2.5.2.\n>> There are two man packages for linux, man and man-db, the latter being a \n>> 90's fork that uses Berkeley DB as a backend to speedup man -k searches \n>> (it helped back then).\n> \n> (I hope git@ will excuse the digression.)\n> \n> Don't be confused by the name. Once upon a time the main feature of\n> man-db was indeed its database; these days that's almost one of the\n\n[snip]\n\nI am sorry Colin, I did not mean to say anything bad, just that there\nare two packages, and as you said... there are differences but nothing\nmajor.  I don't think we want to discuss \"my package > yours\" here\n(although I can of course provide arguments for mine!).\n\nAre you Git guys still interested in this? I actually have recently\nworked on a project where we labeled man pages for subcommands with this\nconvention, so I would welcome the extension for neatness.\n\n Best -F\n\n-- \n_________________________________________\n-- \"'Problem' is a bleak word for challenge\" - Richard Fish\n(Federico L. Lucifredi) - flucifredi@acm.org - GnuPG 0x4A73884C\n"},{"id":"117489","messageId":"4A517966.1060401@acm.org","threadId":"15117","inReplyTo":"20090628023458.297703BC143@sarantium.pelham.vpn.ucam.org","subject":"Re: Suggestion: \"man git clone\"","fromName":"Federico Lucifredi","fromEmail":"flucifredi@acm.org","sentAt":"2009-07-06T04:11:18Z","receivedAt":"2009-07-06T04:11:18Z","isPatch":false,"sender":{"key":"flucifredi@acm.org","avatar":"https://gravatar.com/avatar/b79ecef647be321885840be58ccfa3b1051e47b642984f66d2d16d4fd974e4c9?d=mp&s=160"},"body":"Colin Watson wrote:\n> (Sorry I didn't see this until now. HPA only CCed the maintainer of one\n> of the two man packages popular on Linux-based systems; I'm the other\n> one. I happened to find this thread while searching for something else.)\n> \n\nReally? Sorry, I thought I had added you. My bad.\n\n> In article <48AE143C.8030704@acm.org>, Federico Lucifredi wrote:\n>> Jeff King wrote:\n>>> On Thu, Aug 21, 2008 at 08:07:56PM -0400, Federico Lucifredi wrote:\n>>>> I am all for bass-ackwards compatibility, and I think the suggestion of  \n>>>> going on \"man foo bar\" :\n>>>>\n>>>>  1) look for foo-bar; if success, terminate search\n>>>>  2) look for foo\n>>>>  3) look for bar\n>>>>  ....\n>>>>\n>>>> may be acceptable - I don't see drawbacks at a first glance, and it would \n>>>> allow for groups of pages to be meaningful.\n> \n> I think this is a sensible enough compromise, especially given an option\n> to disable it. The code would be a little ugly, but *shrug* not that\n> bad. The extra stat is cheap enough.\n> \n\nSounds good to me :)\n\n> Using a plain 'git' section for this in order to provoke the\n> happenstance of 'man git clone' working is definitely wrong as far as\n> the manual page hierarchy goes; it means that things like searching for\n> just user commands (section 1) that contain some term will fail. Putting\n> them in section '1git' (i.e. section 1 with a git \"extension\") would be\n> more in line with how manual pages are typically laid out, and at least\n> with man-db would not require any configuration file changes. However, I\n> think both of these are suboptimal. Section extensions are typically\n> used for things like functions or modules in other programming\n> languages, or sometimes for cases where file names would otherwise\n> clash. I'm not much of a git user myself, but I don't get the impression\n> that most git users think of 'git clone' as analogous to a 'clone'\n> command in a hypothetical 'git' programming language; it's closer to an\n> ordinary user command.\n> \n> The only case where I've seen subcommands given their own unprefixed\n> manual pages with only the section extension to tell them apart is\n> OpenSSL, with pages like x509(1ssl). IME, this is very confusing and not\n> a good example to follow: firstly, you can't trivially find a list of\n> all the subcommands with something like 'apropos openssl-'; secondly,\n> it's easy to miss that you're dealing with an openssl subcommand unless\n> you keep your eyes peeled.\n> \n> Short of some mechanism for git to provide a plug-in to man to tell it\n> where to find subpages (eek! potential overengineering alert!), a\n> foo-bar lookup seems tolerable enough.\n> \n>>> Personally I have never ever wanted to see two manpages from one man\n>>> invocation, so I have no real problem with that assumption.\n>> I expected as much, and we should have an option to disable the \"new\" \n>> behavior as a safety anyway.\n> \n> Would you like to suggest an option name for this, so that we can avoid\n> unnecessary divergence? Perhaps something like --separate?\n\nthe option to trigger \"classic\" behavior? How about --no-subpages?\n\n> \n>>>> Are you willing to put your patch where your mouth is? :-)\n>>> I've never looked at man code before, but there seem to be at least two\n>>> man packages for Linux. My boxes have man-db 2.5.2.\n>> There are two man packages for linux, man and man-db, the latter being a \n>> 90's fork that uses Berkeley DB as a backend to speedup man -k searches \n>> (it helped back then).\n> \n> (I hope git@ will excuse the digression.)\n> \n> Don't be confused by the name. Once upon a time the main feature of\n> man-db was indeed its database; these days that's almost one of the\n\n[snip]\n\nI am sorry Colin, I did not mean to say anything bad, just that there\nare two packages, and as you said... there are differences but nothing\nmajor.  I don't think we want to discuss \"my package > yours\" here\n(although I can of course provide arguments for mine!).\n\nAre you Git guys still interested in this? I actually have recently\nworked on a project where we labeled man pages for subcommands with this\nconvention, so I would welcome the extension for neatness.\n\n Best -F\n\n-- \n_________________________________________\n-- \"'Problem' is a bleak word for challenge\" - Richard Fish\n(Federico L. Lucifredi) - flucifredi@acm.org - GnuPG 0x4A73884C\n"}]}