{"thread":{"id":"16542","subject":"[PATCH] Modified the default git help message to be grouped by topic","startedAt":"2008-12-01T17:30:37Z","lastAt":"2008-12-03T00:47:56Z","messageCount":12,"participants":["Scott Chacon","Jeff King","Junio C Hamano","James Pickens","Boyd Stephen Smith Jr.","Johannes Schindelin","Jakub Narebski"],"isPatch":true,"patchVersion":1,"patchTotal":null},"messages":[{"id":"96874","messageId":"20081201173037.GA41967@agadorsparticus","threadId":"16542","inReplyTo":null,"subject":"[PATCH] Modified the default git help message to be grouped by topic","fromName":"Scott Chacon","fromEmail":"schacon@gmail.com","sentAt":"2008-12-01T17:30:37Z","receivedAt":"2008-12-01T17:30:37Z","isPatch":true,"sender":{"key":"schacon@gmail.com","avatar":"https://gravatar.com/avatar/9b13a8a078e1dcf8588c4eea9554445d51ebed6c41b51f56f4d96738130b05c6?d=mp&s=160"},"body":"It's difficult to process 21 commands (which is what is output\nby default for git when no command is given).  I've re-grouped\nthem into 4 groups of 5 or 6 commands each, which I think is\nclearer and easier for new users to process.\n\nAs discussed at the GitTogether.\n\nSigned-off-by: Scott Chacon <schacon@gmail.com>\n---\n\nThis makes the 'git' (with no arguments) command look like this:\nhttp://gist.github.com/20553\n\nThis won't automatically update with the common-commands.txt file,\nbut I think it is easier to parse for the command you may be looking\nfor.\n\n builtin-help.c |   42 +++++++++++++++++++++++++++++-------------\n 1 files changed, 29 insertions(+), 13 deletions(-)\n\ndiff --git a/builtin-help.c b/builtin-help.c\nindex f076efa..562d5d1 100644\n--- a/builtin-help.c\n+++ b/builtin-help.c\n@@ -277,19 +277,35 @@ static struct cmdnames main_cmds, other_cmds;\n \n void list_common_cmds_help(void)\n {\n-\tint i, longest = 0;\n-\n-\tfor (i = 0; i < ARRAY_SIZE(common_cmds); i++) {\n-\t\tif (longest < strlen(common_cmds[i].name))\n-\t\t\tlongest = strlen(common_cmds[i].name);\n-\t}\n-\n-\tputs(\"The most commonly used git commands are:\");\n-\tfor (i = 0; i < ARRAY_SIZE(common_cmds); i++) {\n-\t\tprintf(\"   %s   \", common_cmds[i].name);\n-\t\tmput_char(' ', longest - strlen(common_cmds[i].name));\n-\t\tputs(common_cmds[i].help);\n-\t}\n+\tputs(\"The most commonly used git commands are:\\n\\\n+\\n\\\n+Basic Commands\\n\\\n+  init       Create an empty git repository or reinitialize an existing one\\n\\\n+  add        Add file contents to the staging area\\n\\\n+  status     Show the working tree and staging area status\\n\\\n+  commit     Record changes in the staging area to the repository\\n\\\n+  rm         Remove files from the working tree and from the index\\n\\\n+  mv         Move or rename a file, a directory, or a symlink\\n\\\n+\\n\\\n+History Commands\\n\\\n+  log        Show commit log history\\n\\\n+  diff       Show changes between commits, commit and working tree, etc\\n\\\n+  grep       Print lines in git tracked files matching a pattern\\n\\\n+  reset      Reset current HEAD to the specified state\\n\\\n+  show       Show various types of objects\\n\\\n+\\n\\\n+Branch Commands\\n\\\n+  checkout   Checkout a branch or paths to the working tree\\n\\\n+  branch     List, create, or delete branches\\n\\\n+  merge      Join two or more development histories together\\n\\\n+  rebase     Apply changes introduced in one branch onto another\\n\\\n+  tag        Create, list, delete or verify a tag object signed with GPG\\n\\\n+\\n\\\n+Remote Commands\\n\\\n+  clone      Clone a repository into a new directory\\n\\\n+  fetch      Download objects and refs from another repository\\n\\\n+  pull       Fetch from and merge with another repository or a local branch\\n\\\n+  push       Update remote refs along with associated objects\");\n }\n \n static int is_git_command(const char *s)\n-- \n1.6.0.8.gc9c8\n"},{"id":"96884","messageId":"20081201183258.GB24443@coredump.intra.peff.net","threadId":"16542","inReplyTo":"20081201173037.GA41967@agadorsparticus","subject":"Re: [PATCH] Modified the default git help message to be grouped by topic","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2008-12-01T18:32:59Z","receivedAt":"2008-12-01T18:32:59Z","isPatch":true,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Mon, Dec 01, 2008 at 09:30:37AM -0800, Scott Chacon wrote:\n\n> It's difficult to process 21 commands (which is what is output\n> by default for git when no command is given).  I've re-grouped\n> them into 4 groups of 5 or 6 commands each, which I think is\n> clearer and easier for new users to process.\n\nI like it (and I think the categorizations look reasonable, which is\nsomething that I recall caused some discussion at the GitTogether).\n\nThe only downside I see is that we're now >24 lines.\n\n> This won't automatically update with the common-commands.txt file,\n> but I think it is easier to parse for the command you may be looking\n> for.\n\nPersonally, I don't see a big problem. This is not a list that should\nchange very frequently, and there is extra information here that would\nbe annoying to encode in the list. But since the \"common\" flag in\ncommand-list.txt and the common-cmds.h file would no longer be used,\nthey should probably be removed.\n\n-Peff\n"},{"id":"96901","messageId":"7v7i6jqriv.fsf@gitster.siamese.dyndns.org","threadId":"16542","inReplyTo":"20081201183258.GB24443@coredump.intra.peff.net","subject":"Re: [PATCH] Modified the default git help message to be grouped by topic","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2008-12-02T01:45:12Z","receivedAt":"2008-12-02T01:45:12Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Jeff King <peff@peff.net> writes:\n\n> On Mon, Dec 01, 2008 at 09:30:37AM -0800, Scott Chacon wrote:\n>\n>> It's difficult to process 21 commands (which is what is output\n>> by default for git when no command is given).  I've re-grouped\n>> them into 4 groups of 5 or 6 commands each, which I think is\n>> clearer and easier for new users to process.\n>\n> I like it (and I think the categorizations look reasonable, which is\n> something that I recall caused some discussion at the GitTogether).\n>\n> The only downside I see is that we're now >24 lines.\n\nIf this list is meant to show \"the most commonly used\" basics, then you\ncan trim the list somewhat.  For example, \"rm\" and \"mv\" can be safely\ndiscarded, \"status\" can be replaced with \"diff\", and \"diff\" can be removed\nfrom \"History Commands\".\n"},{"id":"96929","messageId":"d411cc4a0812012210h4cb59974sbda71abd2c64f93b@mail.gmail.com","threadId":"16542","inReplyTo":"7v7i6jqriv.fsf@gitster.siamese.dyndns.org","subject":"Re: [PATCH] Modified the default git help message to be grouped by topic","fromName":"Scott Chacon","fromEmail":"schacon@gmail.com","sentAt":"2008-12-02T06:10:25Z","receivedAt":"2008-12-02T06:10:25Z","isPatch":true,"sender":{"key":"schacon@gmail.com","avatar":"https://gravatar.com/avatar/9b13a8a078e1dcf8588c4eea9554445d51ebed6c41b51f56f4d96738130b05c6?d=mp&s=160"},"body":"Hi,\n\nOn Mon, Dec 1, 2008 at 5:45 PM, Junio C Hamano <gitster@pobox.com> wrote:\n> Jeff King <peff@peff.net> writes:\n>\n>> On Mon, Dec 01, 2008 at 09:30:37AM -0800, Scott Chacon wrote:\n>>\n>>> It's difficult to process 21 commands (which is what is output\n>>> by default for git when no command is given).  I've re-grouped\n>>> them into 4 groups of 5 or 6 commands each, which I think is\n>>> clearer and easier for new users to process.\n>>\n>> I like it (and I think the categorizations look reasonable, which is\n>> something that I recall caused some discussion at the GitTogether).\n>>\n>> The only downside I see is that we're now >24 lines.\n>\n> If this list is meant to show \"the most commonly used\" basics, then you\n> can trim the list somewhat.  For example, \"rm\" and \"mv\" can be safely\n> discarded, \"status\" can be replaced with \"diff\", and \"diff\" can be removed\n> from \"History Commands\".\n>\n\nI sent a new patch that removes 'rm' and 'mv' and removes the\ncommon-cmd.h build process. I did keep the 'status' command, since in\nmy personal experience people tend to like having that command.\n\nScott\n"},{"id":"96979","messageId":"885649360812021211u3d547982i8e1c3070972363e8@mail.gmail.com","threadId":"16542","inReplyTo":"d411cc4a0812012210h4cb59974sbda71abd2c64f93b@mail.gmail.com","subject":"Re: [PATCH] Modified the default git help message to be grouped by topic","fromName":"James Pickens","fromEmail":"jepicken@gmail.com","sentAt":"2008-12-02T20:11:25Z","receivedAt":"2008-12-02T20:11:25Z","isPatch":true,"sender":{"key":"jepicken@gmail.com","avatar":null},"body":"On Mon, Dec 1, 2008 at 11:10 PM, Scott Chacon <schacon@gmail.com> wrote:\n> Hi,\n>\n> On Mon, Dec 1, 2008 at 5:45 PM, Junio C Hamano <gitster@pobox.com> wrote:\n>> If this list is meant to show \"the most commonly used\" basics, then you\n>> can trim the list somewhat.  For example, \"rm\" and \"mv\" can be safely\n>> discarded, \"status\" can be replaced with \"diff\", and \"diff\" can be removed\n>> from \"History Commands\".\n>>\n>\n> I sent a new patch that removes 'rm' and 'mv' and removes the\n> common-cmd.h build process. I did keep the 'status' command, since in\n> my personal experience people tend to like having that command.\n\nEven though 'rm' might not be used very often, I think it's an important\nenough command that it should not be removed from the 'basics' list.\nAFAIK, the only other way to delete a file is 'rm file' followed by 'git\nadd -u' or 'git commit -a'.  Imagine a git newbie trying to figure that\nout.\n\nI'm tempted to say the same thing about 'mv' as well.  And FWIW, I use\n'status' a lot more than I use 'diff', so I would vote to keep 'status' in\nthe list too.\n\nJames\n"},{"id":"96985","messageId":"200812021533.42114.bss03@volumehost.net","threadId":"16542","inReplyTo":"885649360812021211u3d547982i8e1c3070972363e8@mail.gmail.com","subject":"Re: [PATCH] Modified the default git help message to be grouped by topic","fromName":"Boyd Stephen Smith Jr.","fromEmail":"bss03@volumehost.net","sentAt":"2008-12-02T21:33:41Z","receivedAt":"2008-12-02T21:33:41Z","isPatch":true,"sender":{"key":"bss03@volumehost.net","avatar":"https://gravatar.com/avatar/74fa10b37dfd44462a6a30c4d4e3bda26ab7991ddb0d8ab24b022714a8ecb918?d=mp&s=160"},"body":"On Tuesday 02 December 2008, \"James Pickens\" <jepicken@gmail.com> wrote \nabout 'Re: [PATCH] Modified the default git help message to be grouped by \ntopic':\n>On Mon, Dec 1, 2008 at 11:10 PM, Scott Chacon <schacon@gmail.com> wrote:\n>> I sent a new patch that removes 'rm' and 'mv' and removes the\n>> common-cmd.h build process. I did keep the 'status' command, since in\n>> my personal experience people tend to like having that command.\n>\n>Even though 'rm' might not be used very often, I think it's an important\n>enough command that it should not be removed from the 'basics' list.\n>AFAIK, the only other way to delete a file is 'rm file' followed by 'git\n>add -u' or 'git commit -a'.  Imagine a git newbie trying to figure that\n>out.\n>\n>I'm tempted to say the same thing about 'mv' as well.  And FWIW, I use\n>'status' a lot more than I use 'diff', so I would vote to keep 'status'\n> in the list too.\n\nx2 to all of both paragraphs, except that I'm not just \"tempted\"; I do say \nthat mv should be kept.\n-- \nBoyd Stephen Smith Jr.                     ,= ,-_-. =. \nbss03@volumehost.net                      ((_/)o o(\\_))\nICQ: 514984 YM/AIM: DaTwinkDaddy           `-'(. .)`-' \nhttp://iguanasuicide.org/                      \\_/     \n"},{"id":"96991","messageId":"alpine.DEB.1.00.0812022353410.27091@racer","threadId":"16542","inReplyTo":"885649360812021211u3d547982i8e1c3070972363e8@mail.gmail.com","subject":"Re: [PATCH] Modified the default git help message to be grouped by topic","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2008-12-02T22:55:03Z","receivedAt":"2008-12-02T22:55:03Z","isPatch":true,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi,\n\nOn Tue, 2 Dec 2008, James Pickens wrote:\n\n> On Mon, Dec 1, 2008 at 11:10 PM, Scott Chacon <schacon@gmail.com> wrote:\n>\n> > On Mon, Dec 1, 2008 at 5:45 PM, Junio C Hamano <gitster@pobox.com> wrote:\n> >> If this list is meant to show \"the most commonly used\" basics, then \n> >> you can trim the list somewhat.  For example, \"rm\" and \"mv\" can be \n> >> safely discarded, \"status\" can be replaced with \"diff\", and \"diff\" \n> >> can be removed from \"History Commands\".\n> >\n> > I sent a new patch that removes 'rm' and 'mv' and removes the \n> > common-cmd.h build process. I did keep the 'status' command, since in \n> > my personal experience people tend to like having that command.\n> \n> Even though 'rm' might not be used very often, I think it's an important \n> enough command that it should not be removed from the 'basics' list. \n> AFAIK, the only other way to delete a file is 'rm file' followed by 'git \n> add -u' or 'git commit -a'.  Imagine a git newbie trying to figure that \n> out.\n> \n> I'm tempted to say the same thing about 'mv' as well.  And FWIW, I use \n> 'status' a lot more than I use 'diff', so I would vote to keep 'status' \n> in the list too.\n\nIf the whole thing gets longer than 24 lines, we have to leave some things \nout.  Personally, I consider rm and mv unimportant enough that they could \nbe shown in an extended list, but be left out of the summary page.\n\nCiao,\nDscho\n"},{"id":"96994","messageId":"20081202233004.GA22379@coredump.intra.peff.net","threadId":"16542","inReplyTo":"alpine.DEB.1.00.0812022353410.27091@racer","subject":"Re: [PATCH] Modified the default git help message to be grouped by topic","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2008-12-02T23:30:04Z","receivedAt":"2008-12-02T23:30:04Z","isPatch":true,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Tue, Dec 02, 2008 at 11:55:03PM +0100, Johannes Schindelin wrote:\n\n> If the whole thing gets longer than 24 lines, we have to leave some things \n> out.  Personally, I consider rm and mv unimportant enough that they could \n> be shown in an extended list, but be left out of the summary page.\n\nFor the record, the current output is 26 lines, plus you probably want\nto account for 1 line of the user's next shell prompt. So we are 3 lines\nover already.\n\nScott's proposal is about grouping the commands more sensibly. Many of\nthe complaints are about the length of the output. Maybe we should scrap\nhaving a list of commands altogether and just point at section-specific\ndocumentation, each of which could discuss basic commands related to it.\n\nI think there has been mention of task-oriented documentation pointers\nbefore, and I think this is a place where we would want it.\n\n-Peff\n"},{"id":"96996","messageId":"d411cc4a0812021539g34d3a94bn7e873f8cf04adc56@mail.gmail.com","threadId":"16542","inReplyTo":"20081202233004.GA22379@coredump.intra.peff.net","subject":"Re: [PATCH] Modified the default git help message to be grouped by topic","fromName":"Scott Chacon","fromEmail":"schacon@gmail.com","sentAt":"2008-12-02T23:39:43Z","receivedAt":"2008-12-02T23:39:43Z","isPatch":true,"sender":{"key":"schacon@gmail.com","avatar":"https://gravatar.com/avatar/9b13a8a078e1dcf8588c4eea9554445d51ebed6c41b51f56f4d96738130b05c6?d=mp&s=160"},"body":"Hi,\n\nOn Tue, Dec 2, 2008 at 3:30 PM, Jeff King <peff@peff.net> wrote:\n> On Tue, Dec 02, 2008 at 11:55:03PM +0100, Johannes Schindelin wrote:\n>\n>> If the whole thing gets longer than 24 lines, we have to leave some things\n>> out.  Personally, I consider rm and mv unimportant enough that they could\n>> be shown in an extended list, but be left out of the summary page.\n>\n> For the record, the current output is 26 lines, plus you probably want\n> to account for 1 line of the user's next shell prompt. So we are 3 lines\n> over already.\n>\n> Scott's proposal is about grouping the commands more sensibly. Many of\n> the complaints are about the length of the output. Maybe we should scrap\n> having a list of commands altogether and just point at section-specific\n> documentation, each of which could discuss basic commands related to it.\n\nI've always felt it was helpful to newcomers to have that page there\nwith the couple dozen commands you might use - mostly in case you've\nforgotten what the exact command name was.  Hg does something like 'hg\nhelp' which gives you more commands, but I feel like just having the\nquick cheat-sheet is generally really helpful.  If someone just wants\nto remember what the command 'checkout' was, I wouldn't want them to\nhave to go to two places - one to look up what the task document was\nand then another to view that.\n\nMy $0.02\n\n> I think there has been mention of task-oriented documentation pointers\n> before, and I think this is a place where we would want it.\n>\n> -Peff\n>\n\nScott\n"},{"id":"96998","messageId":"7vfxl6m84g.fsf@gitster.siamese.dyndns.org","threadId":"16542","inReplyTo":"20081202233004.GA22379@coredump.intra.peff.net","subject":"Re: [PATCH] Modified the default git help message to be grouped by topic","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2008-12-03T00:10:07Z","receivedAt":"2008-12-03T00:10:07Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Jeff King <peff@peff.net> writes:\n\n> On Tue, Dec 02, 2008 at 11:55:03PM +0100, Johannes Schindelin wrote:\n>\n>> If the whole thing gets longer than 24 lines, we have to leave some things \n>> out.  Personally, I consider rm and mv unimportant enough that they could \n>> be shown in an extended list, but be left out of the summary page.\n>\n> For the record, the current output is 26 lines, plus you probably want\n> to account for 1 line of the user's next shell prompt. So we are 3 lines\n> over already.\n>\n> Scott's proposal is about grouping the commands more sensibly. Many of\n> the complaints are about the length of the output. Maybe we should scrap\n> having a list of commands altogether and just point at section-specific\n> documentation, each of which could discuss basic commands related to it.\n>\n> I think there has been mention of task-oriented documentation pointers\n> before, and I think this is a place where we would want it.\n\nIt might not be a bad idea to make this \"top page help\" into an\ninteractive hierarchical help topic browser.  You would start a page that\nmight look like this:\n\n    Bootstrapping -- preparing an area to work in\n        init, clone\n    Basic -- review, undo and record your changes\n        diff, status, checkout <path>, add, reset, commit\n    History -- inspect what you have now, and what happened before\n        log, blame, grep, show\n    Branching and Merging -- build and use alternate histories\n\tbranch, checkout -b, merge, rebase\n    Working with Others\n\tremote, fetch, pull, push\n\nwith each of the command and the heading being a \"link\" (use ncurses for\nthat).  If you choose the leaf-level command (say, 'diff'), you will get\nthe git-diff(1) manual page.  If you pick one of the headings, say,\n\"Basic\", you may get a more extended description of commands in the\ncategory, that may include other basic commands not in the front page,\nperhaps, like this:\n\n    (review)\n    diff HEAD: view what you did since the last commit\n    diff: view what you did since you last added\n    diff --cached: view what you already added\n    status: list what are added and changes yet to be added\n\n    (undo)\n    checkout path...: checkout a copy from the staging area\n    checkout HEAD path...: checkout a copy from the last commit\n    reset: undo earlier \"git add\" to the staging area\n    reset path...: do so only for the named paths\n\n    (record)\n    mv path1 path2: move the state of path1 to path2\n    rm path2: remove path2\n    rm --cached path2: do so without losing the copy in the working tree\n    add: add the contents to the staging area\n    add -p: do so interactively, hunk by hunk\n    commit: record the changes you added to the staging area\n    commit path...: record all the changes to the paths, ignoring\n    \tchanges you added to the staging area for other paths.\n\nand again each element can be a \"link\".\n"},{"id":"97000","messageId":"20081203003731.GA23780@coredump.intra.peff.net","threadId":"16542","inReplyTo":"7vfxl6m84g.fsf@gitster.siamese.dyndns.org","subject":"Re: [PATCH] Modified the default git help message to be grouped by topic","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2008-12-03T00:37:31Z","receivedAt":"2008-12-03T00:37:31Z","isPatch":true,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Tue, Dec 02, 2008 at 04:10:07PM -0800, Junio C Hamano wrote:\n\n> It might not be a bad idea to make this \"top page help\" into an\n> interactive hierarchical help topic browser.  You would start a page that\n> might look like this:\n> \n>     Bootstrapping -- preparing an area to work in\n>         init, clone\n>     Basic -- review, undo and record your changes\n>         diff, status, checkout <path>, add, reset, commit\n>     History -- inspect what you have now, and what happened before\n>         log, blame, grep, show\n>     Branching and Merging -- build and use alternate histories\n> \tbranch, checkout -b, merge, rebase\n>     Working with Others\n> \tremote, fetch, pull, push\n\nYes, that is the sort of thing I was thinking of. And I think your\nlayout addresses Scott's concern, which is to keep names of commands\navailable for quick reference. So really we are ditching the\ndescriptions.\n\n> with each of the command and the heading being a \"link\" (use ncurses for\n> that).  If you choose the leaf-level command (say, 'diff'), you will get\n\nI'm not sure we need anything so fancy. I was thinking of something\nlike:\n\n  Bootstrapping -- preparing an area to work in (bootstrapping)\n    init, clone\n  ...\n  Working with Others (others)\n    remote, fetch, pull, push\n\n  Use \"git help <subject>\" for more help on one of these subjects, or\n  \"git help <command>\" for help with a specific command.\n\nAnd maybe the \"(bootstrapping)\" could be typographically more obvious as\nthe subject keyword, but I think you get the point (and for\n\"Bootstrapping\", it's obvious what the keyword would be, but for\n\"Working with Others\" it's not).\n\nAnd obviously something with ncurses would save you typing, but I have\nno desire to recreate \"info\" or \"lynx\" here (and I also think that \"git\"\nor \"git foo\" displaying help should remain non-interactive to cause the\nleast surprise).\n\n-Peff\n"},{"id":"97001","messageId":"gh4kub$rh3$1@ger.gmane.org","threadId":"16542","inReplyTo":"7vfxl6m84g.fsf@gitster.siamese.dyndns.org","subject":"Re: [PATCH] Modified the default git help message to be grouped by topic","fromName":"Jakub Narebski","fromEmail":"jnareb@gmail.com","sentAt":"2008-12-03T00:47:56Z","receivedAt":"2008-12-03T00:47:56Z","isPatch":true,"sender":{"key":"jnareb@gmail.com","avatar":"https://avatars.githubusercontent.com/u/2706?v=4"},"body":"Junio C Hamano wrote:\n\n> Jeff King <peff@peff.net> writes:\n> \n>> On Tue, Dec 02, 2008 at 11:55:03PM +0100, Johannes Schindelin wrote:\n>>\n>>> If the whole thing gets longer than 24 lines, we have to leave some things \n>>> out.  Personally, I consider rm and mv unimportant enough that they could \n>>> be shown in an extended list, but be left out of the summary page.\n>>\n>> For the record, the current output is 26 lines, plus you probably want\n>> to account for 1 line of the user's next shell prompt. So we are 3 lines\n>> over already.\n>>\n>> Scott's proposal is about grouping the commands more sensibly. Many of\n>> the complaints are about the length of the output. Maybe we should scrap\n>> having a list of commands altogether and just point at section-specific\n>> documentation, each of which could discuss basic commands related to it.\n>>\n>> I think there has been mention of task-oriented documentation pointers\n>> before, and I think this is a place where we would want it.\n> \n> It might not be a bad idea to make this \"top page help\" into an\n> interactive hierarchical help topic browser.\n\nIsn't that info?\n\n-- \nJakub Narebski\nWarsaw, Poland\nShadeHawk on #git\n"}]}