{"thread":{"id":"49428","subject":"[PATCH] help: allow redirecting to help for aliased command","startedAt":"2018-09-26T10:26:44Z","lastAt":"2018-10-12T03:17:42Z","messageCount":43,"participants":["Rasmus Villemoes","Taylor Blau","Junio C Hamano","Duy Nguyen","Jeff King"],"isPatch":true,"patchVersion":1,"patchTotal":null},"messages":[{"id":"358935","messageId":"20180926102636.30691-1-rv@rasmusvillemoes.dk","threadId":"49428","inReplyTo":null,"subject":"[PATCH] help: allow redirecting to help for aliased command","fromName":"Rasmus Villemoes","fromEmail":"rv@rasmusvillemoes.dk","sentAt":"2018-09-26T10:26:36Z","receivedAt":"2018-09-26T10:26:44Z","isPatch":true,"sender":{"key":"rv@rasmusvillemoes.dk","avatar":"https://avatars.githubusercontent.com/u/4375908?v=4"},"body":"I often use 'git --help' as a quick way to get the documentation\nfor a command. However, I've also trained my muscle memory to use my\naliases (cp=cherry-pick, co=checkout etc.), which means that I often end\nup doing\n\n git cp --help\n\nto which git correctly informs me that cp is an alias for\ncherry-pick. However, I already knew that, and what I really wanted was\nthe man page for the cherry-pick command.\n\nThis introduces a help.followAlias config option that transparently\nredirects to (the first word of) the alias text (provided of course it\nis not a shell command), similar to the option for autocorrect of\nmisspelled commands.\n\nThe documentation in config.txt could probably be improved. Also, I\nmimicked the autocorrect case in that the \"Continuing to ...\" text goes\nto stderr, but because of that, I also print the \"is aliased to\" text to\nstderr, which is different from the current behaviour of using\nstdout. I'm not sure what the most correct thing is, but I assume --help\nis mostly used interactively with stdout and stderr pointing at the same\nplace.\n\nSigned-off-by: Rasmus Villemoes \n---\n Documentation/config.txt | 10 ++++++++++\n builtin/help.c | 36 +++++++++++++++++++++++++++++++++---\n 2 files changed, 43 insertions(+), 3 deletions(-)\n\ndiff --git a/Documentation/config.txt b/Documentation/config.txt\nindex ad0f4510c3..8a1fc8064e 100644\n--- a/Documentation/config.txt\n+++ b/Documentation/config.txt\n@@ -2105,6 +2105,16 @@ help.autoCorrect::\n \tvalue is 0 - the command will be just shown but not executed.\n \tThis is the default.\n \n+help.followAlias::\n+\tWhen requesting help for an alias, git prints a line of the\n+\tform \"'' is aliased to ''\". If this option is\n+\tset to a positive integer, git proceeds to show the help for\n+\tthe first word of after the given number of\n+\tdeciseconds. If the value of this option is negative, the\n+\tredirect happens immediately. If the value is 0 (which is the\n+\tdefault), or begins with an exclamation point, no\n+\tredirect takes place.\n+\n help.htmlPath::\n \tSpecify the path where the HTML documentation resides. File system paths\n \tand URLs are supported. HTML pages will be prefixed with this path when\ndiff --git a/builtin/help.c b/builtin/help.c\nindex 8d4f6dd301..ef1c3f0916 100644\n--- a/builtin/help.c\n+++ b/builtin/help.c\n@@ -34,6 +34,7 @@ enum help_format {\n };\n \n static const char *html_path;\n+static int follow_alias;\n \n static int show_all = 0;\n static int show_guides = 0;\n@@ -273,6 +274,10 @@ static int git_help_config(const char *var, const char *value, void *cb)\n \t\thtml_path = xstrdup(value);\n \t\treturn 0;\n \t}\n+\tif (!strcmp(var, \"help.followalias\")) {\n+\t\tfollow_alias = git_config_int(var, value);\n+\t\treturn 0;\n+\t}\n \tif (!strcmp(var, \"man.viewer\")) {\n \t\tif (!value)\n \t\t\treturn config_error_nonbool(var);\n@@ -415,9 +420,34 @@ static const char *check_git_cmd(const char* cmd)\n \n \talias = alias_lookup(cmd);\n \tif (alias) {\n-\t\tprintf_ln(_(\"'%s' is aliased to '%s'\"), cmd, alias);\n-\t\tfree(alias);\n-\t\texit(0);\n+\t\tconst char **argv;\n+\t\tint count;\n+\n+\t\tif (!follow_alias || alias[0] == '!') {\n+\t\t\tprintf_ln(_(\"'%s' is aliased to '%s'\"), cmd, alias);\n+\t\t\tfree(alias);\n+\t\t\texit(0);\n+\t\t}\n+\t\tfprintf_ln(stderr, _(\"'%s' is aliased to '%s'\"), cmd, alias);\n+\n+\t\t/*\n+\t\t * We use split_cmdline() to get the first word of the\n+\t\t * alias, to ensure that we use the same rules as when\n+\t\t * the alias is actually used. split_cmdline()\n+\t\t * modifies alias in-place.\n+\t\t */\n+\t\tcount = split_cmdline(alias, &argv);\n+\t\tif (count < 0)\n+\t\t\tdie(\"Bad alias.%s string: %s\", cmd,\n+\t\t\t split_cmdline_strerror(count));\n+\n+\t\tif (follow_alias > 0) {\n+\t\t\tfprintf_ln(stderr,\n+\t\t\t\t _(\"Continuing to help for %s in %0.1f seconds.\"),\n+\t\t\t\t alias, follow_alias/10.0);\n+\t\t\tsleep_millisec(follow_alias * 100);\n+\t\t}\n+\t\treturn alias;\n \t}\n \n \tif (exclude_guides)\n-- \n2.16.4\n\n"},{"id":"358945","messageId":"20180926143708.GD25697@syl","threadId":"49428","inReplyTo":"20180926102636.30691-1-rv@rasmusvillemoes.dk","subject":"Re: [PATCH] help: allow redirecting to help for aliased command","fromName":"Taylor Blau","fromEmail":"me@ttaylorr.com","sentAt":"2018-09-26T14:37:08Z","receivedAt":"2018-09-26T14:37:14Z","isPatch":true,"sender":{"key":"me@ttaylorr.com","avatar":"https://avatars.githubusercontent.com/u/301000140?v=4"},"body":"On Wed, Sep 26, 2018 at 12:26:36PM +0200, Rasmus Villemoes wrote:\n> I often use 'git --help' as a quick way to get the documentation\n> for a command. However, I've also trained my muscle memory to use my\n> aliases (cp=cherry-pick, co=checkout etc.), which means that I often end\n> up doing\n>\n> git cp --help\n>\n> to which git correctly informs me that cp is an alias for\n> cherry-pick. However, I already knew that, and what I really wanted was\n> the man page for the cherry-pick command.\n\nNeat. I have many of those such aliases myself, and have always wanted\nsomething like this. Thanks for taking the time to put such a patch\ntogether :-).\n\n> This introduces a help.followAlias config option that transparently\n> redirects to (the first word of) the alias text (provided of course it\n> is not a shell command), similar to the option for autocorrect of\n> misspelled commands.\n\nGood. I was curious if you were going to introduce a convention along\nthe lines of, \"If the alias begins with a '!', then pass \"--help\" to it\nand it must respond appropriately.\" I'm glad that you didn't take that\napproach.\n\n> The documentation in config.txt could probably be improved. Also, I\n> mimicked the autocorrect case in that the \"Continuing to ...\" text goes\n> to stderr, but because of that, I also print the \"is aliased to\" text to\n> stderr, which is different from the current behaviour of using\n> stdout. I'm not sure what the most correct thing is, but I assume --help\n> is mostly used interactively with stdout and stderr pointing at the same\n> place.\n>\n> Signed-off-by: Rasmus Villemoes \n> ---\n> Documentation/config.txt | 10 ++++++++++\n> builtin/help.c | 36 +++++++++++++++++++++++++++++++++---\n> 2 files changed, 43 insertions(+), 3 deletions(-)\n>\n> diff --git a/Documentation/config.txt b/Documentation/config.txt\n> index ad0f4510c3..8a1fc8064e 100644\n> --- a/Documentation/config.txt\n> +++ b/Documentation/config.txt\n> @@ -2105,6 +2105,16 @@ help.autoCorrect::\n> \tvalue is 0 - the command will be just shown but not executed.\n> \tThis is the default.\n>\n> +help.followAlias::\n> +\tWhen requesting help for an alias, git prints a line of the\n> +\tform \"'' is aliased to ''\". If this option is\n> +\tset to a positive integer, git proceeds to show the help for\n\nWith regard to \"set to a positive integer\", I'm not sure why this is the\nway that it is. I see below you used 'git_config_int()', but I think\nthat 'git_config_bool()' would be more appropriate.\n\nThe later understands strings like \"yes\", \"on\" or \"true\", which I think\nis more of what I would expect from a configuration setting such as\nthis.\n\n> +\tthe first word of after the given number of\n> +\tdeciseconds. If the value of this option is negative, the\n> +\tredirect happens immediately. If the value is 0 (which is the\n> +\tdefault), or begins with an exclamation point, no\n> +\tredirect takes place.\n\nIt was unclear to my originlly why this was given as a configuration\nknob, but my understanding after reading the patch is that this is to do\n_additional_ things besides printing what is aliased to what.\n\nCould you perhaps note this in the documentation?\n\n> help.htmlPath::\n> \tSpecify the path where the HTML documentation resides. File system paths\n> \tand URLs are supported. HTML pages will be prefixed with this path when\n> diff --git a/builtin/help.c b/builtin/help.c\n> index 8d4f6dd301..ef1c3f0916 100644\n> --- a/builtin/help.c\n> +++ b/builtin/help.c\n> @@ -34,6 +34,7 @@ enum help_format {\n> };\n>\n> static const char *html_path;\n> +static int follow_alias;\n>\n> static int show_all = 0;\n> static int show_guides = 0;\n> @@ -273,6 +274,10 @@ static int git_help_config(const char *var, const char *value, void *cb)\n> \t\thtml_path = xstrdup(value);\n> \t\treturn 0;\n> \t}\n> +\tif (!strcmp(var, \"help.followalias\")) {\n> +\t\tfollow_alias = git_config_int(var, value);\n> +\t\treturn 0;\n> +\t}\n\nGood. I think in modern Git, we'd prefer to write this as a series of\n`else if`'s, but this matches the style of the surrounding code. I think\nthat you could optionally clean up this style as a preparatory commit,\nbut ultimately I don't think it's worth a reroll on its own.\n\n> \tif (!strcmp(var, \"man.viewer\")) {\n> \t\tif (!value)\n> \t\t\treturn config_error_nonbool(var);\n> @@ -415,9 +420,34 @@ static const char *check_git_cmd(const char* cmd)\n>\n> \talias = alias_lookup(cmd);\n> \tif (alias) {\n> -\t\tprintf_ln(_(\"'%s' is aliased to '%s'\"), cmd, alias);\n> -\t\tfree(alias);\n> -\t\texit(0);\n> +\t\tconst char **argv;\n> +\t\tint count;\n> +\n> +\t\tif (!follow_alias || alias[0] == '!') {\n> +\t\t\tprintf_ln(_(\"'%s' is aliased to '%s'\"), cmd, alias);\n> +\t\t\tfree(alias);\n> +\t\t\texit(0);\n> +\t\t}\n> +\t\tfprintf_ln(stderr, _(\"'%s' is aliased to '%s'\"), cmd, alias);\n\nOK, I think that this is a sensible decision: print to STDERR when\nthat's not the main purpose of what're doing (e.g., we're going to\nfollow the alias momentarily), and STDOUT when it's the only thing we're\ndoing.\n\nPotentially we could call 'fprintf_ln()' only once, and track an `int\nfd` at the top of this block.\n\n> +\n> +\t\t/*\n> +\t\t * We use split_cmdline() to get the first word of the\n> +\t\t * alias, to ensure that we use the same rules as when\n> +\t\t * the alias is actually used. split_cmdline()\n> +\t\t * modifies alias in-place.\n> +\t\t */\n> +\t\tcount = split_cmdline(alias, &argv);\n> +\t\tif (count < 0)\n> +\t\t\tdie(\"Bad alias.%s string: %s\", cmd,\n> +\t\t\t split_cmdline_strerror(count));\n\nPlease wrap this in _() so that translators can translate it.\n\n> +\t\tif (follow_alias > 0) {\n> +\t\t\tfprintf_ln(stderr,\n> +\t\t\t\t _(\"Continuing to help for %s in %0.1f seconds.\"),\n> +\t\t\t\t alias, follow_alias/10.0);\n> +\t\t\tsleep_millisec(follow_alias * 100);\n> +\t\t}\n> +\t\treturn alias;\n\nI'm not sure that this notification is necessary, but I'll defer to the\njudgement of others on this one.\n\nThanks,\nTaylor\n"},{"id":"358946","messageId":"xmqqzhw4mgq3.fsf@gitster-ct.c.googlers.com","threadId":"49428","inReplyTo":"20180926102636.30691-1-rv@rasmusvillemoes.dk","subject":"Re: [PATCH] help: allow redirecting to help for aliased command","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2018-09-26T15:16:36Z","receivedAt":"2018-09-26T15:16:43Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Rasmus Villemoes writes:\n\n> I often use 'git --help' as a quick way to get the documentation\n> for a command. However, I've also trained my muscle memory to use my\n> aliases (cp=cherry-pick, co=checkout etc.), which means that I often end\n> up doing\n>\n> git cp --help\n>\n> to which git correctly informs me that cp is an alias for\n> cherry-pick. However, I already knew that, and what I really wanted was\n> the man page for the cherry-pick command.\n>\n> This introduces a help.followAlias config option that transparently\n> redirects to (the first word of) the alias text (provided of course it\n> is not a shell command), similar to the option for autocorrect of\n> misspelled commands.\n\nWhile I do agree with you that it would sometimes be very handy if\n\"git cp --help\" behaved identically to \"git cherry-pick --help\" just\nlike \"git cp -h\" behaves identically to \"git cherry-pick -h\" when\nyou have \"[alias] cp = cherry-pick\", I do not think help.followAlias\nconfiguration is a good idea. I may know, perhaps because I use it\nall the time, by heart that \"cp\" is aliased to \"cherry-pick\" and\nwant \"git cp --help\" to directly give me the manpage, but I may not\nremember if \"co\" was commit or checkout and want to be concisely\ntold that it is aliased to checkout without seeing the full manpage.\nWhich means you'd want some way to command line override anyway, and\nhaving to say \"git -c help.followAlias=false cp --help\" is not a\ngreat solution.\n\nIf we expect users to use \"git cp --help\" a lot more often than \"git\nhelp cp\" (or the other way around), one way to give a nicer experience\nmay be to unconditionally make \"git cp --help\" to directly show the\nmanpage of cherry-pick, while keeping \"git help cp\" to never do\nthat. Then those who want to remember what \"co\" is aliased to can\nask \"git help co\".\n\n> +\t\t/*\n> +\t\t * We use split_cmdline() to get the first word of the\n> +\t\t * alias, to ensure that we use the same rules as when\n> +\t\t * the alias is actually used. split_cmdline()\n> +\t\t * modifies alias in-place.\n> +\t\t */\n> +\t\tcount = split_cmdline(alias, &argv);\n> +\t\tif (count < 0)\n> +\t\t\tdie(\"Bad alias.%s string: %s\", cmd,\n> +\t\t\t split_cmdline_strerror(count));\n> +\n> +\t\tif (follow_alias > 0) {\n> +\t\t\tfprintf_ln(stderr,\n> +\t\t\t\t _(\"Continuing to help for %s in %0.1f seconds.\"),\n> +\t\t\t\t alias, follow_alias/10.0);\n> +\t\t\tsleep_millisec(follow_alias * 100);\n> +\t\t}\n> +\t\treturn alias;\n\nIf you have \"[alias] cp = cherry-pick -n\", split_cmdline discards\n\"-n\" and the follow-alias prompt does not even tell you that it did\nso, and you get \"git help cherry-pick\". This code somehow expects\nyou to know to jump to the section that describes the \"--no-commit\"\noption. I do not think that is a reasonable expectation.\n\nWhen you have \"[alias] cp = cherry-pick -n\", \"git cp --help\" should\nnot do \"git help cherry-pick\". Only a single word that exactly\nmatches a git command should get this treatment.\n\n> \t}\n> \n> \tif (exclude_guides)\n"},{"id":"358947","messageId":"CACsJy8Ac0TEpfHK6-pS_CMzGrYjmkaT_bM0V4kXfNxqY0TONtg@mail.gmail.com","threadId":"49428","inReplyTo":"20180926102636.30691-1-rv@rasmusvillemoes.dk","subject":"Re: [PATCH] help: allow redirecting to help for aliased command","fromName":"Duy Nguyen","fromEmail":"pclouds@gmail.com","sentAt":"2018-09-26T15:16:34Z","receivedAt":"2018-09-26T15:17:03Z","isPatch":true,"sender":{"key":"pclouds@gmail.com","avatar":"https://avatars.githubusercontent.com/u/720?v=4"},"body":"On Wed, Sep 26, 2018 at 12:29 PM Rasmus Villemoes wrote:\n>\n> I often use 'git --help' as a quick way to get the documentation\n> for a command. However, I've also trained my muscle memory to use my\n> aliases (cp=cherry-pick, co=checkout etc.), which means that I often end\n> up doing\n>\n> git cp --help\n>\n> to which git correctly informs me that cp is an alias for\n> cherry-pick. However, I already knew that, and what I really wanted was\n> the man page for the cherry-pick command.\n>\n> This introduces a help.followAlias config option that transparently\n> redirects to (the first word of) the alias text (provided of course it\n> is not a shell command), similar to the option for autocorrect of\n> misspelled commands.\n>\n> The documentation in config.txt could probably be improved.\n\nWhile at there, maybe you could also mention the behavior of \"git\nhelp\" when given an alias, in git-help.txt. And you could also add a\nhint to suggest this new config help.followAlias there.\n-- \nDuy\n"},{"id":"358948","messageId":"CACsJy8AQbJPVNtcVEsLH-iiXw2TPABr3LsgZ779h3KMvR98yZQ@mail.gmail.com","threadId":"49428","inReplyTo":"20180926143708.GD25697@syl","subject":"Re: [PATCH] help: allow redirecting to help for aliased command","fromName":"Duy Nguyen","fromEmail":"pclouds@gmail.com","sentAt":"2018-09-26T15:19:00Z","receivedAt":"2018-09-26T15:19:29Z","isPatch":true,"sender":{"key":"pclouds@gmail.com","avatar":"https://avatars.githubusercontent.com/u/720?v=4"},"body":"On Wed, Sep 26, 2018 at 4:42 PM Taylor Blau wrote:\n> > +\n> > + /*\n> > + * We use split_cmdline() to get the first word of the\n> > + * alias, to ensure that we use the same rules as when\n> > + * the alias is actually used. split_cmdline()\n> > + * modifies alias in-place.\n> > + */\n> > + count = split_cmdline(alias, &argv);\n> > + if (count < 0)\n> > + die(\"Bad alias.%s string: %s\", cmd,\n> > + split_cmdline_strerror(count));\n>\n> Please wrap this in _() so that translators can translate it.\n\nYes! And another nit. die(), error(), warning()... usually start the\nmessage with a lowercase letter because we already start the sentence\nwith a prefix, like\n\nfatal: bad alias.blah blah\n-- \nDuy\n"},{"id":"358950","messageId":"xmqqtvmcmg2v.fsf@gitster-ct.c.googlers.com","threadId":"49428","inReplyTo":"20180926143708.GD25697@syl","subject":"Re: [PATCH] help: allow redirecting to help for aliased command","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2018-09-26T15:30:32Z","receivedAt":"2018-09-26T15:30:38Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Taylor Blau writes:\n\n>> +help.followAlias::\n>> +\tWhen requesting help for an alias, git prints a line of the\n>> +\tform \"'' is aliased to ''\". If this option is\n>> +\tset to a positive integer, git proceeds to show the help for\n>\n> With regard to \"set to a positive integer\", I'm not sure why this is the\n> way that it is. I see below you used 'git_config_int()', but I think\n> that 'git_config_bool()' would be more appropriate.\n>\n> The later understands strings like \"yes\", \"on\" or \"true\", which I think\n> is more of what I would expect from a configuration setting such as\n> this.\n\nThat is, as you read in the next paragraph, because it gives the\nnumber of deciseconds to show a prompt before showing the manpage.\n\nNot that I think this configuration is a good idea (see my review).\n\n>> +\tthe first word of after the given number of\n>> +\tdeciseconds. If the value of this option is negative, the\n>> +\tredirect happens immediately. If the value is 0 (which is the\n>> +\tdefault), or begins with an exclamation point, no\n>> +\tredirect takes place.\n>\n> It was unclear to my originlly why this was given as a configuration\n> knob, but my understanding after reading the patch is that this is to do\n> _additional_ things besides printing what is aliased to what.\n>\n> Could you perhaps note this in the documentation?\n\nIt may be that the description for the \"execute the likely typoed\ncommand\" configuration is poorly written and this merely copied the\nbadness from it. Over there the prompt gives a chance to ^C out,\nwhich serves useful purpose, and if that is not documented, we should.\n\nOn the other hand, I'd rather see this prompt in the new code\nremoved, because I do not think the prompt given in the new code\nhere is all that useful.\n\n>> @@ -415,9 +420,34 @@ static const char *check_git_cmd(const char* cmd)\n>>\n>> \talias = alias_lookup(cmd);\n>> \tif (alias) {\n>> -\t\tprintf_ln(_(\"'%s' is aliased to '%s'\"), cmd, alias);\n>> -\t\tfree(alias);\n>> -\t\texit(0);\n>> +\t\tconst char **argv;\n>> +\t\tint count;\n>> +\n>> +\t\tif (!follow_alias || alias[0] == '!') {\n>> +\t\t\tprintf_ln(_(\"'%s' is aliased to '%s'\"), cmd, alias);\n>> +\t\t\tfree(alias);\n>> +\t\t\texit(0);\n>> +\t\t}\n>> +\t\tfprintf_ln(stderr, _(\"'%s' is aliased to '%s'\"), cmd, alias);\n>\n> OK, I think that this is a sensible decision: print to STDERR when\n> that's not the main purpose of what're doing (e.g., we're going to\n> follow the alias momentarily), and STDOUT when it's the only thing we're\n> doing.\n\n> Potentially we could call 'fprintf_ln()' only once, and track an `int\n> fd` at the top of this block.\n\nI actually think this should always give the output to standard output.\n\n>> +\n>> +\t\t/*\n>> +\t\t * We use split_cmdline() to get the first word of the\n>> +\t\t * alias, to ensure that we use the same rules as when\n>> +\t\t * the alias is actually used. split_cmdline()\n>> +\t\t * modifies alias in-place.\n>> +\t\t */\n>> +\t\tcount = split_cmdline(alias, &argv);\n>> +\t\tif (count < 0)\n>> +\t\t\tdie(\"Bad alias.%s string: %s\", cmd,\n>> +\t\t\t split_cmdline_strerror(count));\n>\n> Please wrap this in _() so that translators can translate it.\n>\n>> +\t\tif (follow_alias > 0) {\n>> +\t\t\tfprintf_ln(stderr,\n>> +\t\t\t\t _(\"Continuing to help for %s in %0.1f seconds.\"),\n>> +\t\t\t\t alias, follow_alias/10.0);\n>> +\t\t\tsleep_millisec(follow_alias * 100);\n>> +\t\t}\n>> +\t\treturn alias;\n>\n> I'm not sure that this notification is necessary, but I'll defer to the\n> judgement of others on this one.\n\nI didn't bother to check the original but this is mimicking an\nexisting code that lets configuration to be set to num-deciseconds\nto pause and give chance to ^C out, and also allows it to be set to\nnegative to immediately go ahead. follow-alias at this point cannot\nbe zero in the codeflow, but it still can be negative.\n"},{"id":"358964","messageId":"20180926180911.GA63889@syl","threadId":"49428","inReplyTo":"xmqqtvmcmg2v.fsf@gitster-ct.c.googlers.com","subject":"Re: [PATCH] help: allow redirecting to help for aliased command","fromName":"Taylor Blau","fromEmail":"me@ttaylorr.com","sentAt":"2018-09-26T18:09:11Z","receivedAt":"2018-09-26T18:09:16Z","isPatch":true,"sender":{"key":"me@ttaylorr.com","avatar":"https://avatars.githubusercontent.com/u/301000140?v=4"},"body":"On Wed, Sep 26, 2018 at 08:30:32AM -0700, Junio C Hamano wrote:\n> Taylor Blau writes:\n>\n> >> +help.followAlias::\n> >> +\tWhen requesting help for an alias, git prints a line of the\n> >> +\tform \"'' is aliased to ''\". If this option is\n> >> +\tset to a positive integer, git proceeds to show the help for\n> >\n> > With regard to \"set to a positive integer\", I'm not sure why this is the\n> > way that it is. I see below you used 'git_config_int()', but I think\n> > that 'git_config_bool()' would be more appropriate.\n> >\n> > The later understands strings like \"yes\", \"on\" or \"true\", which I think\n> > is more of what I would expect from a configuration setting such as\n> > this.\n>\n> That is, as you read in the next paragraph, because it gives the\n> number of deciseconds to show a prompt before showing the manpage.\n>\n> Not that I think this configuration is a good idea (see my review).\n>\n> >> +\tthe first word of after the given number of\n> >> +\tdeciseconds. If the value of this option is negative, the\n> >> +\tredirect happens immediately. If the value is 0 (which is the\n> >> +\tdefault), or begins with an exclamation point, no\n> >> +\tredirect takes place.\n> >\n> > It was unclear to my originlly why this was given as a configuration\n> > knob, but my understanding after reading the patch is that this is to do\n> > _additional_ things besides printing what is aliased to what.\n> >\n> > Could you perhaps note this in the documentation?\n>\n> It may be that the description for the \"execute the likely typoed\n> command\" configuration is poorly written and this merely copied the\n> badness from it. Over there the prompt gives a chance to ^C out,\n> which serves useful purpose, and if that is not documented, we should.\n>\n> On the other hand, I'd rather see this prompt in the new code\n> removed, because I do not think the prompt given in the new code\n> here is all that useful.\n>\n> >> @@ -415,9 +420,34 @@ static const char *check_git_cmd(const char* cmd)\n> >>\n> >> \talias = alias_lookup(cmd);\n> >> \tif (alias) {\n> >> -\t\tprintf_ln(_(\"'%s' is aliased to '%s'\"), cmd, alias);\n> >> -\t\tfree(alias);\n> >> -\t\texit(0);\n> >> +\t\tconst char **argv;\n> >> +\t\tint count;\n> >> +\n> >> +\t\tif (!follow_alias || alias[0] == '!') {\n> >> +\t\t\tprintf_ln(_(\"'%s' is aliased to '%s'\"), cmd, alias);\n> >> +\t\t\tfree(alias);\n> >> +\t\t\texit(0);\n> >> +\t\t}\n> >> +\t\tfprintf_ln(stderr, _(\"'%s' is aliased to '%s'\"), cmd, alias);\n> >\n> > OK, I think that this is a sensible decision: print to STDERR when\n> > that's not the main purpose of what're doing (e.g., we're going to\n> > follow the alias momentarily), and STDOUT when it's the only thing we're\n> > doing.\n>\n> > Potentially we could call 'fprintf_ln()' only once, and track an `int\n> > fd` at the top of this block.\n>\n> I actually think this should always give the output to standard output.\n>\n> >> +\n> >> +\t\t/*\n> >> +\t\t * We use split_cmdline() to get the first word of the\n> >> +\t\t * alias, to ensure that we use the same rules as when\n> >> +\t\t * the alias is actually used. split_cmdline()\n> >> +\t\t * modifies alias in-place.\n> >> +\t\t */\n> >> +\t\tcount = split_cmdline(alias, &argv);\n> >> +\t\tif (count < 0)\n> >> +\t\t\tdie(\"Bad alias.%s string: %s\", cmd,\n> >> +\t\t\t split_cmdline_strerror(count));\n> >\n> > Please wrap this in _() so that translators can translate it.\n> >\n> >> +\t\tif (follow_alias > 0) {\n> >> +\t\t\tfprintf_ln(stderr,\n> >> +\t\t\t\t _(\"Continuing to help for %s in %0.1f seconds.\"),\n> >> +\t\t\t\t alias, follow_alias/10.0);\n> >> +\t\t\tsleep_millisec(follow_alias * 100);\n> >> +\t\t}\n> >> +\t\treturn alias;\n> >\n> > I'm not sure that this notification is necessary, but I'll defer to the\n> > judgement of others on this one.\n>\n> I didn't bother to check the original but this is mimicking an\n> existing code that lets configuration to be set to num-deciseconds\n> to pause and give chance to ^C out, and also allows it to be set to\n> negative to immediately go ahead. follow-alias at this point cannot\n> be zero in the codeflow, but it still can be negative.\n\nI think that this is the most compelling argument _for_ the configuration\nthat you are not in favor of. I understood your previous review as \"I\nknow that 'git cp' is a synonym of 'git cherry-pick', but I want to use\n'git co --help' for when I don't remember what 'git co' is a synonym\nof.\"\n\nThis pause (though I'm a little surprised by it when reviewing the\ncode), I think strikes a good balance between the two, i.e., that you\ncan get help for whatever it is aliased to, and see what that alias is.\n\nThanks,\nTaylor\n"},{"id":"358966","messageId":"20180926181251.GB63889@syl","threadId":"49428","inReplyTo":"xmqqzhw4mgq3.fsf@gitster-ct.c.googlers.com","subject":"Re: [PATCH] help: allow redirecting to help for aliased command","fromName":"Taylor Blau","fromEmail":"me@ttaylorr.com","sentAt":"2018-09-26T18:12:51Z","receivedAt":"2018-09-26T18:13:01Z","isPatch":true,"sender":{"key":"me@ttaylorr.com","avatar":"https://avatars.githubusercontent.com/u/301000140?v=4"},"body":"On Wed, Sep 26, 2018 at 08:16:36AM -0700, Junio C Hamano wrote:\n> Rasmus Villemoes writes:\n>\n> > I often use 'git --help' as a quick way to get the documentation\n> > for a command. However, I've also trained my muscle memory to use my\n> > aliases (cp=cherry-pick, co=checkout etc.), which means that I often end\n> > up doing\n> >\n> > git cp --help\n> >\n> > to which git correctly informs me that cp is an alias for\n> > cherry-pick. However, I already knew that, and what I really wanted was\n> > the man page for the cherry-pick command.\n> >\n> > This introduces a help.followAlias config option that transparently\n> > redirects to (the first word of) the alias text (provided of course it\n> > is not a shell command), similar to the option for autocorrect of\n> > misspelled commands.\n>\n> While I do agree with you that it would sometimes be very handy if\n> \"git cp --help\" behaved identically to \"git cherry-pick --help\" just\n> like \"git cp -h\" behaves identically to \"git cherry-pick -h\" when\n> you have \"[alias] cp = cherry-pick\", I do not think help.followAlias\n> configuration is a good idea. I may know, perhaps because I use it\n> all the time, by heart that \"cp\" is aliased to \"cherry-pick\" and\n> want \"git cp --help\" to directly give me the manpage, but I may not\n> remember if \"co\" was commit or checkout and want to be concisely\n> told that it is aliased to checkout without seeing the full manpage.\n> Which means you'd want some way to command line override anyway, and\n> having to say \"git -c help.followAlias=false cp --help\" is not a\n> great solution.\n\nI think I responded partially to this hunk in another thread, but I\nthink I can add some additional information here where it is more\nrelevant.\n\nOne approach to take when digesting this is that 'git co --help' shows\nyou the manual page for 'git-checkout(1)' (or whatever you have it\naliased to), so that answers the question for the caller who has a\nterminal open.\n\nIn the case where you are scripting (and want to know what 'git co'\nmeans for programmatic usage), I think that there are two options. One,\nwhich you note above, is the 'git -c help.followAlias=false ...'\napproach, which I don't think is so bad for callers, given the tradeoff.\n\nAnother way to go is 'git config alias.co', which should provide the\nsame answer. I think that either would be fine.\n\nPerhaps we could assume that 'help.followAlias' is false when it is\nunset, _and_ isatty(2) says that we aren't a TTY. Otherwise, since I\nfeel that this is a good feature that should be the new default, we can\nassume it's set to true.\n\nThanks,\nTaylor\n"},{"id":"358969","messageId":"xmqqh8icktmp.fsf@gitster-ct.c.googlers.com","threadId":"49428","inReplyTo":"20180926180911.GA63889@syl","subject":"Re: [PATCH] help: allow redirecting to help for aliased command","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2018-09-26T18:20:46Z","receivedAt":"2018-09-26T18:20:51Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Taylor Blau writes:\n\n> This pause (though I'm a little surprised by it when reviewing the\n> code), I think strikes a good balance between the two, i.e., that you\n> can get help for whatever it is aliased to, and see what that alias is.\n\nAnd I need to react to it within subsecond with ^C when I want a\ncompact answer to \"what is this aliased to\"? No, thanks.\n"},{"id":"358978","messageId":"20180926184914.GC30680@sigill.intra.peff.net","threadId":"49428","inReplyTo":"xmqqzhw4mgq3.fsf@gitster-ct.c.googlers.com","subject":"Re: [PATCH] help: allow redirecting to help for aliased command","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2018-09-26T18:49:15Z","receivedAt":"2018-09-26T18:49:18Z","isPatch":true,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Wed, Sep 26, 2018 at 08:16:36AM -0700, Junio C Hamano wrote:\n\n> > This introduces a help.followAlias config option that transparently\n> > redirects to (the first word of) the alias text (provided of course it\n> > is not a shell command), similar to the option for autocorrect of\n> > misspelled commands.\n> \n> While I do agree with you that it would sometimes be very handy if\n> \"git cp --help\" behaved identically to \"git cherry-pick --help\" just\n> like \"git cp -h\" behaves identically to \"git cherry-pick -h\" when\n> you have \"[alias] cp = cherry-pick\", I do not think help.followAlias\n> configuration is a good idea. I may know, perhaps because I use it\n> all the time, by heart that \"cp\" is aliased to \"cherry-pick\" and\n> want \"git cp --help\" to directly give me the manpage, but I may not\n> remember if \"co\" was commit or checkout and want to be concisely\n> told that it is aliased to checkout without seeing the full manpage.\n> Which means you'd want some way to command line override anyway, and\n> having to say \"git -c help.followAlias=false cp --help\" is not a\n> great solution.\n> \n> If we expect users to use \"git cp --help\" a lot more often than \"git\n> help cp\" (or the other way around), one way to give a nicer experience\n> may be to unconditionally make \"git cp --help\" to directly show the\n> manpage of cherry-pick, while keeping \"git help cp\" to never do\n> that. Then those who want to remember what \"co\" is aliased to can\n> ask \"git help co\".\n\nI like that direction much better. I also wondered if we could leverage\nthe \"-h\" versus \"--help\" distinction. The problem with printing the\nalias definition along with \"--help\" is that the latter will start a\npager that obliterates what we wrote before (and hence all of this delay\ntrickery).\n\nBut for \"-h\" we generally expect the command to output a usage message.\n\nSo what if the rules were:\n\n - \"git help cp\" shows \"cp is an alias for cherry-pick\" (as it does\n now)\n\n - \"git cp -h\" shows \"cp is an alias for cherry-pick\", followed by\n actually running \"cherry-pick -h\", which will show the usage\n message. For a single-word command that does very little, since the\n usage message starts with \"cherry-pick\". But if your alias is\n actually \"cp = cherry-pick -n\", then it _is_ telling you extra\n information. And this could even work with \"!\" aliases: we define\n it, and then it is up to the alias to handle \"-h\" sensibly.\n\n - \"git cp --help\" opens the manpage for cherry-pick. We don't bother\n with the alias definition, as it's available through other means\n (and thus we skip the obliteration/timing thing totally).\n\n This really only works for non-! aliases. Those would continue to\n show the alias definition.\n\n\n> If you have \"[alias] cp = cherry-pick -n\", split_cmdline discards\n> \"-n\" and the follow-alias prompt does not even tell you that it did\n> so, and you get \"git help cherry-pick\". This code somehow expects\n> you to know to jump to the section that describes the \"--no-commit\"\n> option. I do not think that is a reasonable expectation.\n> \n> When you have \"[alias] cp = cherry-pick -n\", \"git cp --help\" should\n> not do \"git help cherry-pick\". Only a single word that exactly\n> matches a git command should get this treatment.\n\nI'm not sure I agree. A plausible scenario (under the rules I gave\nabove) is:\n\n $ git cp -h\n 'cp' is aliased to 'cherry-pick -n'\n usage: git cherry-pick ...\n\n $ git cp --help\n\nI.e., you already know the \"-n\" part, and now you want to dig further.\nOf course one could just type \"git cherry-pick --help\" since you also\nknow that, too. But by that rationale, one could already do:\n\n $ git help cp\n $ git help cherry-pick\n\nwithout this patch at all.\n\n-Peff\n"},{"id":"358986","messageId":"xmqqy3bojbs4.fsf@gitster-ct.c.googlers.com","threadId":"49428","inReplyTo":"20180926184914.GC30680@sigill.intra.peff.net","subject":"Re: [PATCH] help: allow redirecting to help for aliased command","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2018-09-26T19:31:39Z","receivedAt":"2018-09-26T19:31:44Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Jeff King writes:\n\n>> When you have \"[alias] cp = cherry-pick -n\", \"git cp --help\" should\n>> not do \"git help cherry-pick\". Only a single word that exactly\n>> matches a git command should get this treatment.\n>\n> I'm not sure I agree. A plausible scenario (under the rules I gave\n> above) is:\n>\n> $ git cp -h\n> 'cp' is aliased to 'cherry-pick -n'\n> usage: git cherry-pick ...\n\nWith that additional rule, I can buy \"it is fine for 'git cp --help'\nto completely ignore -n and behave as if 'git help cherry-pick' was\ngiven\", I think. People already expect \"git cp --help\" to give the\nalias expansion, so to them any change will be a regression any way\nwe cut it---but I think this is the least bad approach.\n\n> $ git cp --help\n>\n> I.e., you already know the \"-n\" part, and now you want to dig further.\n\nOne very good thing about the \"make '--help' go directly to the\nmanpage, while teaching '-h' to report also alias expansion\" is that\npeople already expect \"-h\" is more concise than \"--help\". The\ncurrent output from \"git cp --help\" violates that expectation, and\nthe change you suggest rectifies it.\n\n> Of course one could just type \"git cherry-pick --help\" since you also\n> know that, too.\n\nYeah, but that is not an argument. The user aliased cp because\ncherry-pick was quite a mouthful and do not want to type \"git\ncherry-pick --help\" in the first place.\n"},{"id":"359191","messageId":"fb221514-4749-affa-c657-0e36dd28fb13@rasmusvillemoes.dk","threadId":"49428","inReplyTo":"xmqqzhw4mgq3.fsf@gitster-ct.c.googlers.com","subject":"Re: [PATCH] help: allow redirecting to help for aliased command","fromName":"Rasmus Villemoes","fromEmail":"rv@rasmusvillemoes.dk","sentAt":"2018-09-28T07:40:45Z","receivedAt":"2018-09-28T07:40:52Z","isPatch":true,"sender":{"key":"rv@rasmusvillemoes.dk","avatar":"https://avatars.githubusercontent.com/u/4375908?v=4"},"body":"On 2018-09-26 17:16, Junio C Hamano wrote:\n> Rasmus Villemoes writes:\n> \n>> +\t\t/*\n>> +\t\t * We use split_cmdline() to get the first word of the\n>> +\t\t * alias, to ensure that we use the same rules as when\n>> +\t\t * the alias is actually used. split_cmdline()\n>> +\t\t * modifies alias in-place.\n>> +\t\t */\n>> +\t\tcount = split_cmdline(alias, &argv);\n>> +\t\tif (count < 0)\n>> +\t\t\tdie(\"Bad alias.%s string: %s\", cmd,\n>> +\t\t\t split_cmdline_strerror(count));\n>> +\n>> +\t\tif (follow_alias > 0) {\n>> +\t\t\tfprintf_ln(stderr,\n>> +\t\t\t\t _(\"Continuing to help for %s in %0.1f seconds.\"),\n>> +\t\t\t\t alias, follow_alias/10.0);\n>> +\t\t\tsleep_millisec(follow_alias * 100);\n>> +\t\t}\n>> +\t\treturn alias;\n> \n> If you have \"[alias] cp = cherry-pick -n\", split_cmdline discards\n> \"-n\" and the follow-alias prompt does not even tell you that it did\n> so,\n\nThat's not really true, as I deliberately did the split_cmdline after\nprinting the \"is an alias for\", but before \"continuing to help for\", so\nthis would precisely tell you\n\n cp is an alias for 'cherry-pick -n'\n continuing to help for 'cherry-pick' in 1.5 seconds\n\n> and you get \"git help cherry-pick\". This code somehow expects\n> you to know to jump to the section that describes the \"--no-commit\"\n> option. I do not think that is a reasonable expectation.\n\nNo, in that case I would not expect git cp --help to jump to that\nsection anymore than I would expect \"git cherry-pick -n --help\" to\nmagically do that (and that would be impossible in general, if more\noptions are bundled in the alias).\n\n> When you have \"[alias] cp = cherry-pick -n\", \"git cp --help\" should\n> not do \"git help cherry-pick\". Only a single word that exactly\n> matches a git command should get this treatment.\n\nI considered that, and could certainly live with that. But it seems the\ndiscussion took a different turn in another part of the thread, so I'll\ncontinue there.\n\nRasmus\n"},{"id":"359192","messageId":"e59fd7e3-7755-79b9-4b73-1da991db39b6@rasmusvillemoes.dk","threadId":"49428","inReplyTo":"CACsJy8AQbJPVNtcVEsLH-iiXw2TPABr3LsgZ779h3KMvR98yZQ@mail.gmail.com","subject":"Re: [PATCH] help: allow redirecting to help for aliased command","fromName":"Rasmus Villemoes","fromEmail":"rv@rasmusvillemoes.dk","sentAt":"2018-09-28T07:44:51Z","receivedAt":"2018-09-28T07:44:57Z","isPatch":true,"sender":{"key":"rv@rasmusvillemoes.dk","avatar":"https://avatars.githubusercontent.com/u/4375908?v=4"},"body":"On 2018-09-26 17:19, Duy Nguyen wrote:\n> On Wed, Sep 26, 2018 at 4:42 PM Taylor Blau wrote:\n>>> +\n>>> + /*\n>>> + * We use split_cmdline() to get the first word of the\n>>> + * alias, to ensure that we use the same rules as when\n>>> + * the alias is actually used. split_cmdline()\n>>> + * modifies alias in-place.\n>>> + */\n>>> + count = split_cmdline(alias, &argv);\n>>> + if (count < 0)\n>>> + die(\"Bad alias.%s string: %s\", cmd,\n>>> + split_cmdline_strerror(count));\n>>\n>> Please wrap this in _() so that translators can translate it.\n> \n> Yes! And another nit. die(), error(), warning()... usually start the\n> message with a lowercase letter because we already start the sentence\n> with a prefix, like\n> \n> fatal: bad alias.blah blah\n> \n\nI'll keep these points in mind, but this was pure copy-paste from git.c.\n\nRasmus\n\n"},{"id":"359193","messageId":"1e2397b4-7113-fc27-8d0d-485323144dbc@rasmusvillemoes.dk","threadId":"49428","inReplyTo":"20180926181251.GB63889@syl","subject":"Re: [PATCH] help: allow redirecting to help for aliased command","fromName":"Rasmus Villemoes","fromEmail":"rv@rasmusvillemoes.dk","sentAt":"2018-09-28T07:53:37Z","receivedAt":"2018-09-28T07:53:46Z","isPatch":true,"sender":{"key":"rv@rasmusvillemoes.dk","avatar":"https://avatars.githubusercontent.com/u/4375908?v=4"},"body":"On 2018-09-26 20:12, Taylor Blau wrote:\n> \n> In the case where you are scripting (and want to know what 'git co'\n> means for programmatic usage), I think that there are two options. One,\n> which you note above, is the 'git -c help.followAlias=false ...'\n> approach, which I don't think is so bad for callers, given the tradeoff.\n> \n> Another way to go is 'git config alias.co', which should provide the\n> same answer. I think that either would be fine.\n\nThe latter seems much more robust, since that will also tell you\nprecisely whether co is an alias at all, and you don't have to parse\n-h/--help output (stripping out the 'is aliased to...' stuff, which\nmight be complicated by i18n etc. etc.). So I don't think we should\nworry too much about scripted use of -h/--help.\n\nRasmus\n"},{"id":"359194","messageId":"3677a12b-5b9b-ad2a-1e3a-7de251baa40d@rasmusvillemoes.dk","threadId":"49428","inReplyTo":"20180926184914.GC30680@sigill.intra.peff.net","subject":"Re: [PATCH] help: allow redirecting to help for aliased command","fromName":"Rasmus Villemoes","fromEmail":"rv@rasmusvillemoes.dk","sentAt":"2018-09-28T08:18:05Z","receivedAt":"2018-09-28T08:18:12Z","isPatch":true,"sender":{"key":"rv@rasmusvillemoes.dk","avatar":"https://avatars.githubusercontent.com/u/4375908?v=4"},"body":"On 2018-09-26 20:49, Jeff King wrote:\n> On Wed, Sep 26, 2018 at 08:16:36AM -0700, Junio C Hamano wrote:\n> \n>>\n>> If we expect users to use \"git cp --help\" a lot more often than \"git\n>> help cp\" (or the other way around), one way to give a nicer experience\n>> may be to unconditionally make \"git cp --help\" to directly show the\n>> manpage of cherry-pick, while keeping \"git help cp\" to never do\n>> that. Then those who want to remember what \"co\" is aliased to can\n>> ask \"git help co\".\n> \n> I like that direction much better. I also wondered if we could leverage\n> the \"-h\" versus \"--help\" distinction. The problem with printing the\n> alias definition along with \"--help\" is that the latter will start a\n> pager that obliterates what we wrote before (and hence all of this delay\n> trickery).\n> \n> But for \"-h\" we generally expect the command to output a usage message.\n> \n> So what if the rules were:\n> \n> - \"git help cp\" shows \"cp is an alias for cherry-pick\" (as it does\n> now)\n\nSounds good.\n\n> - \"git cp -h\" shows \"cp is an alias for cherry-pick\", followed by\n> actually running \"cherry-pick -h\", which will show the usage\n> message. For a single-word command that does very little, since the\n> usage message starts with \"cherry-pick\". But if your alias is\n> actually \"cp = cherry-pick -n\", then it _is_ telling you extra\n> information.\n\nFunny, I never noticed this difference, and that '-h' for an alias would\nactually give more information than '--help'. I sort-of knew that -h\nwould give the synopsis, so I guess I've just gotten used to always use\n--help, and just noticed that for aliases that doesn't provide much help.\n\nAdding the 'is an alias for' info to -h sounds quite sensible.\n\nAnd this could even work with \"!\" aliases: we define\n> it, and then it is up to the alias to handle \"-h\" sensibly.\n\nI'd be nervous about doing this, though, especially if we introduce this\nwithout a new opt-in config option (which seems to be the direction the\ndiscussion is taking). There are lots of commands that don't respond\nwith a help message to -h, or that only recognize -h as the first word,\nor... There are really too many ways this could cause headaches.\n\nBut, now that I test it, it seems that we already let the alias handle\n-h (and any other following words, with --help as the first word\nspecial-cased). So what you're suggesting is (correct me if I'm wrong)\nto _also_ intercept -h as the first word, and then print the alias info,\nin addition to spawning the alias with the entire argv as usual. The\nalias info would probably need to go to stderr in this case.\n\n> - \"git cp --help\" opens the manpage for cherry-pick. We don't bother\n> with the alias definition, as it's available through other means\n> (and thus we skip the obliteration/timing thing totally).\n\nIt sounds like you suggest doing this unconditionally, and without any\nopt-in via config option or a short wait? That would certainly work for\nme. It is, in fact, how I expect 'git cp --help' to work, until I get\nreminded that it does not... Also, as Junio noted, is consistent with\n--help generally providing more information than -h - except that one\nloses the 'is an alias for' part for --help.\n\n> This really only works for non-! aliases. Those would continue to\n> show the alias definition.\n\nYes.\n\nThanks,\nRasmus\n"},{"id":"359220","messageId":"xmqqwor5d0af.fsf@gitster-ct.c.googlers.com","threadId":"49428","inReplyTo":"fb221514-4749-affa-c657-0e36dd28fb13@rasmusvillemoes.dk","subject":"Re: [PATCH] help: allow redirecting to help for aliased command","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2018-09-28T17:00:56Z","receivedAt":"2018-09-28T17:01:01Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Rasmus Villemoes writes:\n\n>>> +\t\tif (follow_alias > 0) {\n>>> +\t\t\tfprintf_ln(stderr,\n>>> +\t\t\t\t _(\"Continuing to help for %s in %0.1f seconds.\"),\n>>> +\t\t\t\t alias, follow_alias/10.0);\n>>> +\t\t\tsleep_millisec(follow_alias * 100);\n>>> +\t\t}\n>>> +\t\treturn alias;\n>> \n>> If you have \"[alias] cp = cherry-pick -n\", split_cmdline discards\n>> \"-n\" and the follow-alias prompt does not even tell you that it did\n>> so,\n>\n> That's not really true, as I deliberately did the split_cmdline after\n> printing the \"is an alias for\", but before \"continuing to help for\", so\n> this would precisely tell you\n>\n> cp is an alias for 'cherry-pick -n'\n> continuing to help for 'cherry-pick' in 1.5 seconds\n\nYes, but notice that cherry-pick appears twice---I do not know about\nyou, but I know at least my eyes will be drawn to the last mention\nthat does not have '-n' stronger than the one before/above that\nline.\n\nIn any case, I think Peff's \"Let's teach 'git cp -h' to prefix what\n'cp' is aliased to before invoking 'git cherry-pick -n -h' (and let\nit fail)\" approach is much more robust, so let's do that without\nemulating that command-typo-correction codepath.\n\n\n"},{"id":"359282","messageId":"20180929082108.GJ2174@sigill.intra.peff.net","threadId":"49428","inReplyTo":"3677a12b-5b9b-ad2a-1e3a-7de251baa40d@rasmusvillemoes.dk","subject":"Re: [PATCH] help: allow redirecting to help for aliased command","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2018-09-29T08:21:08Z","receivedAt":"2018-09-29T08:21:12Z","isPatch":true,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Fri, Sep 28, 2018 at 10:18:05AM +0200, Rasmus Villemoes wrote:\n\n> > it, and then it is up to the alias to handle \"-h\" sensibly.\n> \n> I'd be nervous about doing this, though, especially if we introduce this\n> without a new opt-in config option (which seems to be the direction the\n> discussion is taking). There are lots of commands that don't respond\n> with a help message to -h, or that only recognize -h as the first word,\n> or... There are really too many ways this could cause headaches.\n> \n> But, now that I test it, it seems that we already let the alias handle\n> -h (and any other following words, with --help as the first word\n> special-cased). So what you're suggesting is (correct me if I'm wrong)\n> to _also_ intercept -h as the first word, and then print the alias info,\n> in addition to spawning the alias with the entire argv as usual. The\n> alias info would probably need to go to stderr in this case.\n\nRight, I'm proposing only to add the extra message and then continue as\nusual.\n\nIt is a little funny, I guess, if you have a script which doesn't\nrespond to \"-h\", because you'd get our \"foo is aliased to git-bar\"\nmessage to stderr, followed by who-knows-what. But as long as it's to\nstderr (and not stdout), I think it's not likely to _break_ anything.\n\n> > - \"git cp --help\" opens the manpage for cherry-pick. We don't bother\n> > with the alias definition, as it's available through other means\n> > (and thus we skip the obliteration/timing thing totally).\n> \n> It sounds like you suggest doing this unconditionally, and without any\n> opt-in via config option or a short wait? That would certainly work for\n> me. It is, in fact, how I expect 'git cp --help' to work, until I get\n> reminded that it does not... Also, as Junio noted, is consistent with\n> --help generally providing more information than -h - except that one\n> loses the 'is an alias for' part for --help.\n\nYes, I'd suggest doing it always. No config, no wait.\n\n-Peff\n"},{"id":"359301","messageId":"xmqq4le89p91.fsf@gitster-ct.c.googlers.com","threadId":"49428","inReplyTo":"20180929082108.GJ2174@sigill.intra.peff.net","subject":"Re: [PATCH] help: allow redirecting to help for aliased command","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2018-09-29T17:39:54Z","receivedAt":"2018-09-29T17:40:00Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Jeff King writes:\n\n> Right, I'm proposing only to add the extra message and then continue as\n> usual.\n>\n> It is a little funny, I guess, if you have a script which doesn't\n> respond to \"-h\", because you'd get our \"foo is aliased to git-bar\"\n> message to stderr, followed by who-knows-what. But as long as it's to\n> stderr (and not stdout), I think it's not likely to _break_ anything.\n>\n>> > - \"git cp --help\" opens the manpage for cherry-pick. We don't bother\n>> > with the alias definition, as it's available through other means\n>> > (and thus we skip the obliteration/timing thing totally).\n>> \n>> It sounds like you suggest doing this unconditionally, and without any\n>> opt-in via config option or a short wait? That would certainly work for\n>> me. It is, in fact, how I expect 'git cp --help' to work, until I get\n>> reminded that it does not... Also, as Junio noted, is consistent with\n>> --help generally providing more information than -h - except that one\n>> loses the 'is an alias for' part for --help.\n>\n> Yes, I'd suggest doing it always. No config, no wait.\n\nWhile I do think your suggestion is the best among various ones\nfloated in the thread, I just realized there is one potential glitch\neven with that approach. \n\nSuppose \"git foo\" is aliased to a command \"git bar\".\n\nThe best case is when \"git bar -h\" knows that it is asked to give us\na short usage. We get \"foo is aliased to bar\" followed by the short\nusage for \"bar\" and everything is visible above the shell prompt\nafter all that happens.\n\nThe second best case is when \"git bar\" simply does not support \"-h\"\nbut actively notices an unknown option on the command line to give\nthe usage message. We see \"foo is aliased to bar\" followed by \"-h\nis an unknown option; supported options are ...\" and everything is\nvisible above the shell prompt after all that happens.\n\nThe worst case is when \"git bar\" supports or ignores \"-h\" and\nproduces reams of output. Sending the \"aliased to\" message to the\nstandard error means that it is scrolled out when the output is\ndone, or lost even when \"git foo -h | less\" attempts to let the\nreader read before the early part of the output scrolls away.\n\nEven the first two \"better\" cases share the same glitch if the \"foo\nis aliased to bar\" goes to the standard error output. Parse-options\nenabled commands tend to show a long \"-h\" output that you would need\nto say \"git grep -h | less\", losing the \"aliased to\" message.\n\nAt least it seems to me an improvement to use standard output,\ninstead of standard error, for the alias information.\n\nIn practice, however, what the command that \"git foo\" is aliased to\ndoes when given \"-h\" is probably unknown (because the user is asking\nwhat \"git foo\" is in the first place), so perhaps I am worried too\nmuch. When the user does not know if the usage text comes to the\nstandard output or to the standard error, and if the usage text is\nvery long or not, they probably would learn quickly that the safest\nthing to do is to\n\n\t$ git unknown-command -h >&2 | less\n\nAnd at that point, it does not matter which between the standard\noutput and the standard error streams we write \"unknown-command is\naliased to ...\".\n\nSo I dunno.\n"},{"id":"359325","messageId":"20180930042735.GA32120@sigill.intra.peff.net","threadId":"49428","inReplyTo":"xmqq4le89p91.fsf@gitster-ct.c.googlers.com","subject":"Re: [PATCH] help: allow redirecting to help for aliased command","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2018-09-30T04:27:35Z","receivedAt":"2018-09-30T04:27:38Z","isPatch":true,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Sat, Sep 29, 2018 at 10:39:54AM -0700, Junio C Hamano wrote:\n\n> Suppose \"git foo\" is aliased to a command \"git bar\".\n> \n> The best case is when \"git bar -h\" knows that it is asked to give us\n> a short usage. We get \"foo is aliased to bar\" followed by the short\n> usage for \"bar\" and everything is visible above the shell prompt\n> after all that happens.\n> \n> The second best case is when \"git bar\" simply does not support \"-h\"\n> but actively notices an unknown option on the command line to give\n> the usage message. We see \"foo is aliased to bar\" followed by \"-h\n> is an unknown option; supported options are ...\" and everything is\n> visible above the shell prompt after all that happens.\n\nRight, these are the ones we hope for.\n\n> The worst case is when \"git bar\" supports or ignores \"-h\" and\n> produces reams of output. Sending the \"aliased to\" message to the\n> standard error means that it is scrolled out when the output is\n> done, or lost even when \"git foo -h | less\" attempts to let the\n> reader read before the early part of the output scrolls away.\n\nThis is the \"who-knows-what\" case I meant here:\n\n>> It is a little funny, I guess, if you have a script which doesn't\n>> respond to \"-h\", because you'd get our \"foo is aliased to git-bar\"\n>> message to stderr, followed by who-knows-what. But as long as it's to\n>> stderr (and not stdout), I think it's not likely to _break_ anything.\n\nAnd I think this has to be stderr. We're polluting the output of the\naliased command with our extra message, so we have two choices:\n\n 1. Pollute stderr, and risk copious stdout (or a pager) scrolling it\n off the screen.\n\n 2. Pollute stdout, at which point our message may be confused as part\n of the actual output of the command (and that may not even be\n immediately noticed if it is passed through a shell pipeline or\n into a file).\n\nChoice (2) seems like a regression to me. Choice (1) is unfortunate in\nsome cases, but is no worse than today's behavior.\n\n(Obviously I'm not including choices like not running the sub-command at\nall, but I think that would be even worse).\n\n> Even the first two \"better\" cases share the same glitch if the \"foo\n> is aliased to bar\" goes to the standard error output. Parse-options\n> enabled commands tend to show a long \"-h\" output that you would need\n> to say \"git grep -h | less\", losing the \"aliased to\" message.\n> \n> At least it seems to me an improvement to use standard output,\n> instead of standard error, for the alias information.\n\n...so I'd disagree with this.\n\n> In practice, however, what the command that \"git foo\" is aliased to\n> does when given \"-h\" is probably unknown (because the user is asking\n> what \"git foo\" is in the first place), so perhaps I am worried too\n> much. When the user does not know if the usage text comes to the\n> standard output or to the standard error, and if the usage text is\n> very long or not, they probably would learn quickly that the safest\n> thing to do is to\n> \n> \t$ git unknown-command -h >&2 | less\n> \n> And at that point, it does not matter which between the standard\n> output and the standard error streams we write \"unknown-command is\n> aliased to ...\".\n\nYeah. I think if \"git foo -h\" produces a bunch of output you didn't\nexpect, then \"git help foo\" or \"git foo --help\" may be the next thing\nyou reach for. That's not so different than running the command even\nwithout any aliases involved.\n\n-Peff\n"},{"id":"359333","messageId":"xmqqy3bj7dxo.fsf@gitster-ct.c.googlers.com","threadId":"49428","inReplyTo":"20180930042735.GA32120@sigill.intra.peff.net","subject":"Re: [PATCH] help: allow redirecting to help for aliased command","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2018-09-30T05:27:15Z","receivedAt":"2018-09-30T05:27:19Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Jeff King writes:\n\n> And I think this has to be stderr. We're polluting the output of the\n> aliased command with our extra message, so we have two choices:\n>\n> 1. Pollute stderr, and risk copious stdout (or a pager) scrolling it\n> off the screen.\n>\n> 2. Pollute stdout, at which point our message may be confused as part\n> of the actual output of the command (and that may not even be\n> immediately noticed if it is passed through a shell pipeline or\n> into a file).\n>\n> Choice (2) seems like a regression to me. Choice (1) is unfortunate in\n> some cases, but is no worse than today's behavior.\n\nI think the output of \"git foo -h\" changing (i.e. has \"aliased\nto...\" message in front) is about the same degree of regression as\n\"git foo --help\" no longer giving \"aliased to...\" information\nanywhere, though.\n\n>> Even the first two \"better\" cases share the same glitch if the \"foo\n>> ...\n>> thing to do is to\n>> \n>> \t$ git unknown-command -h >&2 | less\n>> \n>> And at that point, it does not matter which between the standard\n>> output and the standard error streams we write \"unknown-command is\n>> aliased to ...\".\n>\n> Yeah. I think if \"git foo -h\" produces a bunch of output you didn't\n> expect, then \"git help foo\" or \"git foo --help\" may be the next thing\n> you reach for. That's not so different than running the command even\n> without any aliases involved.\n\nHmmm. With the \"teach 'git foo -h' to output 'foo is aliased to\nbar' to the standard error before running 'git bar -h'\", plus \"'git\nfoo --help' now goes straight to 'git bar --help'\", \"git foo --help\"\nno longer tells us that foo is aliased to bar. Presumably \"git help\nfoo\" will still give \"foo is bar\" and stop?\n"},{"id":"359335","messageId":"20180930055343.GA2542@sigill.intra.peff.net","threadId":"49428","inReplyTo":"xmqqy3bj7dxo.fsf@gitster-ct.c.googlers.com","subject":"Re: [PATCH] help: allow redirecting to help for aliased command","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2018-09-30T05:53:43Z","receivedAt":"2018-09-30T05:53:48Z","isPatch":true,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Sat, Sep 29, 2018 at 10:27:15PM -0700, Junio C Hamano wrote:\n\n> Jeff King writes:\n> \n> > And I think this has to be stderr. We're polluting the output of the\n> > aliased command with our extra message, so we have two choices:\n> >\n> > 1. Pollute stderr, and risk copious stdout (or a pager) scrolling it\n> > off the screen.\n> >\n> > 2. Pollute stdout, at which point our message may be confused as part\n> > of the actual output of the command (and that may not even be\n> > immediately noticed if it is passed through a shell pipeline or\n> > into a file).\n> >\n> > Choice (2) seems like a regression to me. Choice (1) is unfortunate in\n> > some cases, but is no worse than today's behavior.\n> \n> I think the output of \"git foo -h\" changing (i.e. has \"aliased\n> to...\" message in front) is about the same degree of regression as\n> \"git foo --help\" no longer giving \"aliased to...\" information\n> anywhere, though.\n\nHmm. They seem quite different to me. Changing \"--help\" output is\nsomething that's only going to impact what the user sees (a manpage\nversus the alias message). And the user can follow-up by asking for what\nthey wanted.\n\nWhereas if I have an alias that currently understands \"-h\", and I do\nsomething like:\n\n git foo -h | wc -l\n\nif we output to stdout, that's going to produce subtly broken results.\nBut if we output to stderr instead, then they may see the extra message,\nbut it's obvious what's happening, and it's probably an annoyance at\nworst).\n\n> > Yeah. I think if \"git foo -h\" produces a bunch of output you didn't\n> > expect, then \"git help foo\" or \"git foo --help\" may be the next thing\n> > you reach for. That's not so different than running the command even\n> > without any aliases involved.\n> \n> Hmmm. With the \"teach 'git foo -h' to output 'foo is aliased to\n> bar' to the standard error before running 'git bar -h'\", plus \"'git\n> foo --help' now goes straight to 'git bar --help'\", \"git foo --help\"\n> no longer tells us that foo is aliased to bar. Presumably \"git help\n> foo\" will still give \"foo is bar\" and stop?\n\nYes, that was the intent in the behavior I laid out earlier.\n\n-Peff\n"},{"id":"359353","messageId":"20181001112107.28956-1-rv@rasmusvillemoes.dk","threadId":"49428","inReplyTo":"20180926102636.30691-1-rv@rasmusvillemoes.dk","subject":"[PATCH v2 1/3] help: redirect to aliased commands for \"git cmd --help\"","fromName":"Rasmus Villemoes","fromEmail":"rv@rasmusvillemoes.dk","sentAt":"2018-10-01T11:21:05Z","receivedAt":"2018-10-01T11:21:18Z","isPatch":true,"sender":{"key":"rv@rasmusvillemoes.dk","avatar":"https://avatars.githubusercontent.com/u/4375908?v=4"},"body":"As discussed in the thread for v1 of this patch [1] [2], this changes the\nrules for \"git foo --help\" when foo is an alias.\n\n(0) When invoked as \"git help foo\", we continue to print the \"foo is\naliased to bar\" message and nothing else.\n\n(1) If foo is an alias for a shell command, print \"foo is aliased to\n!bar\" as usual.\n\n(2) Otherwise, break the alias string into words, and pretend that \"git\nword0 --help\" was called.\n\nAt least for me, getting the man page for git-cherry-pick directly with\n\"git cp --help\" is more useful (and how I expect an alias to behave)\nthan the short \"is aliased to\" notice. It is also consistent with\n\"--help\" generally providing more comprehensive help than \"-h\".\n\nI believe that printing the \"is aliased to\" message also in case (2) has\nvalue: Depending on pager setup, or if the user has help.format=web, the\nmessage is still present immediately above the prompt when the user\nquits the pager/returns to the terminal. That serves as an explanation\nfor why one was redirected to \"man git-cherry-pick\" from \"git cp\n--help\", and if cp is actually 'cherry-pick -n', it reminds the user\nthat using cp has some flag implicitly set before firing off the next\ncommand.\n\nIt also provides some useful info in case we end up erroring out, either\nin the \"bad alias string\" check, or in the \"No manual entry for gitbar\"\ncase.\n\n[1] https://public-inbox.org/git/20180926102636.30691-1-rv@rasmusvillemoes.dk/\n[2] https://public-inbox.org/git/20180926184914.GC30680@sigill.intra.peff.net/\n\nSigned-off-by: Rasmus Villemoes \n---\n builtin/help.c | 26 +++++++++++++++++++++++---\n 1 file changed, 23 insertions(+), 3 deletions(-)\n\ndiff --git a/builtin/help.c b/builtin/help.c\nindex 8d4f6dd301..4802a06f37 100644\n--- a/builtin/help.c\n+++ b/builtin/help.c\n@@ -415,9 +415,29 @@ static const char *check_git_cmd(const char* cmd)\n \n \talias = alias_lookup(cmd);\n \tif (alias) {\n-\t\tprintf_ln(_(\"'%s' is aliased to '%s'\"), cmd, alias);\n-\t\tfree(alias);\n-\t\texit(0);\n+\t\tconst char **argv;\n+\t\tint count;\n+\n+\t\t/*\n+\t\t * If we were invoked as \"git help cmd\", or cmd is an\n+\t\t * alias for a shell command, we inform the user what\n+\t\t * cmd is an alias for and do nothing else.\n+\t\t */\n+\t\tif (!exclude_guides || alias[0] == '!') {\n+\t\t\tprintf_ln(_(\"'%s' is aliased to '%s'\"), cmd, alias);\n+\t\t\tfree(alias);\n+\t\t\texit(0);\n+\t\t}\n+\t\t/*\n+\t\t * Otherwise, we pretend that the command was \"git\n+\t\t * word0 --help.\n+\t\t */\n+\t\tfprintf_ln(stderr, _(\"'%s' is aliased to '%s'\"), cmd, alias);\n+\t\tcount = split_cmdline(alias, &argv);\n+\t\tif (count < 0)\n+\t\t\tdie(_(\"bad alias.%s string: %s\"), cmd,\n+\t\t\t split_cmdline_strerror(count));\n+\t\treturn alias;\n \t}\n \n \tif (exclude_guides)\n-- \n2.19.0\n\n"},{"id":"359354","messageId":"20181001112107.28956-2-rv@rasmusvillemoes.dk","threadId":"49428","inReplyTo":"20181001112107.28956-1-rv@rasmusvillemoes.dk","subject":"[PATCH v2 2/3] git.c: handle_alias: prepend alias info when first argument is -h","fromName":"Rasmus Villemoes","fromEmail":"rv@rasmusvillemoes.dk","sentAt":"2018-10-01T11:21:06Z","receivedAt":"2018-10-01T11:21:19Z","isPatch":true,"sender":{"key":"rv@rasmusvillemoes.dk","avatar":"https://avatars.githubusercontent.com/u/4375908?v=4"},"body":"Most git commands respond to -h anywhere in the command line, or at\nleast as a first and lone argument, by printing the usage\ninformation. For aliases, we can provide a little more information that\nmight be useful in interpreting/understanding the following output by\nprepending a line telling that the command is an alias, and for what.\n\nWhen one invokes a simple alias, such as \"cp = cherry-pick\"\nwith -h, this results in\n\n$ git cp -h\n'cp' is aliased to 'cherry-pick'\nusage: git cherry-pick [] ...\n...\n\nWhen the alias consists of more than one word, this provides the\nadditional benefit of informing the user which options are implicit in\nusing the alias, e.g. with \"cp = cherry-pick -n\":\n\n$ git cp -h\n'cp' is aliased to 'cherry-pick -n'\nusage: git cherry-pick [] ...\n...\n\nFor shell commands, we cannot know how it responds to -h, but printing\nthis line to stderr should not hurt, and can help in figuring out what\nis happening in a case like\n\n$ git sc -h\n'sc' is aliased to '!somecommand'\nsomecommand: invalid option '-h'\n\nSuggested-by: Jeff King \nSigned-off-by: Rasmus Villemoes \n---\n git.c | 3 +++\n 1 file changed, 3 insertions(+)\n\ndiff --git a/git.c b/git.c\nindex a6f4b44af5..0211c2d4c0 100644\n--- a/git.c\n+++ b/git.c\n@@ -318,6 +318,9 @@ static int handle_alias(int *argcp, const char ***argv)\n \talias_command = (*argv)[0];\n \talias_string = alias_lookup(alias_command);\n \tif (alias_string) {\n+\t\tif (*argcp > 1 && !strcmp((*argv)[1], \"-h\"))\n+\t\t\tfprintf_ln(stderr, _(\"'%s' is aliased to '%s'\"),\n+\t\t\t\t alias_command, alias_string);\n \t\tif (alias_string[0] == '!') {\n \t\t\tstruct child_process child = CHILD_PROCESS_INIT;\n \t\t\tint nongit_ok;\n-- \n2.19.0\n\n"},{"id":"359355","messageId":"20181001112107.28956-3-rv@rasmusvillemoes.dk","threadId":"49428","inReplyTo":"20181001112107.28956-1-rv@rasmusvillemoes.dk","subject":"[PATCH v2 3/3] git-help.txt: document \"git help cmd\" vs \"git cmd --help\" for aliases","fromName":"Rasmus Villemoes","fromEmail":"rv@rasmusvillemoes.dk","sentAt":"2018-10-01T11:21:07Z","receivedAt":"2018-10-01T11:21:20Z","isPatch":true,"sender":{"key":"rv@rasmusvillemoes.dk","avatar":"https://avatars.githubusercontent.com/u/4375908?v=4"},"body":"This documents the existing behaviour of \"git help cmd\" when cmd is an\nalias, as well as providing a hint to use the \"git cmd --help\" form to\nbe taken directly to the man page for the aliased command.\n\nSigned-off-by: Rasmus Villemoes \n---\n Documentation/git-help.txt | 4 ++++\n 1 file changed, 4 insertions(+)\n\ndiff --git a/Documentation/git-help.txt b/Documentation/git-help.txt\nindex 83d25d825a..37e85868fd 100644\n--- a/Documentation/git-help.txt\n+++ b/Documentation/git-help.txt\n@@ -29,6 +29,10 @@ guide is brought up. The 'man' program is used by default for this\n purpose, but this can be overridden by other options or configuration\n variables.\n \n+If an alias is given, git prints a note explaining what it is an alias\n+for on standard output. To get the manual page for the aliased\n+command, use `git COMMAND --help`.\n+\n Note that `git --help ...` is identical to `git help ...` because the\n former is internally converted into the latter.\n \n-- \n2.19.0\n\n"},{"id":"359488","messageId":"20181003021358.GA20553@sigill.intra.peff.net","threadId":"49428","inReplyTo":"20181001112107.28956-1-rv@rasmusvillemoes.dk","subject":"Re: [PATCH v2 1/3] help: redirect to aliased commands for \"git cmd --help\"","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2018-10-03T02:13:58Z","receivedAt":"2018-10-03T02:18:21Z","isPatch":true,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Mon, Oct 01, 2018 at 01:21:05PM +0200, Rasmus Villemoes wrote:\n\n> As discussed in the thread for v1 of this patch [1] [2], this changes the\n> rules for \"git foo --help\" when foo is an alias.\n> \n> (0) When invoked as \"git help foo\", we continue to print the \"foo is\n> aliased to bar\" message and nothing else.\n> \n> (1) If foo is an alias for a shell command, print \"foo is aliased to\n> !bar\" as usual.\n> \n> (2) Otherwise, break the alias string into words, and pretend that \"git\n> word0 --help\" was called.\n> \n> At least for me, getting the man page for git-cherry-pick directly with\n> \"git cp --help\" is more useful (and how I expect an alias to behave)\n> than the short \"is aliased to\" notice. It is also consistent with\n> \"--help\" generally providing more comprehensive help than \"-h\".\n\nMakes sense.\n\n> I believe that printing the \"is aliased to\" message also in case (2) has\n> value: Depending on pager setup, or if the user has help.format=web, the\n> message is still present immediately above the prompt when the user\n> quits the pager/returns to the terminal. That serves as an explanation\n> for why one was redirected to \"man git-cherry-pick\" from \"git cp\n> --help\", and if cp is actually 'cherry-pick -n', it reminds the user\n> that using cp has some flag implicitly set before firing off the next\n> command.\n> \n> It also provides some useful info in case we end up erroring out, either\n> in the \"bad alias string\" check, or in the \"No manual entry for gitbar\"\n> case.\n\nOK, I buy that line of reasoning. And in the other cases, it shouldn't\n_hurt_ anything.\n\n> diff --git a/builtin/help.c b/builtin/help.c\n> index 8d4f6dd301..4802a06f37 100644\n> --- a/builtin/help.c\n> +++ b/builtin/help.c\n> @@ -415,9 +415,29 @@ static const char *check_git_cmd(const char* cmd)\n> \n> \talias = alias_lookup(cmd);\n> \tif (alias) {\n> -\t\tprintf_ln(_(\"'%s' is aliased to '%s'\"), cmd, alias);\n> -\t\tfree(alias);\n> -\t\texit(0);\n> +\t\tconst char **argv;\n> +\t\tint count;\n> +\n> +\t\t/*\n> +\t\t * If we were invoked as \"git help cmd\", or cmd is an\n> +\t\t * alias for a shell command, we inform the user what\n> +\t\t * cmd is an alias for and do nothing else.\n> +\t\t */\n> +\t\tif (!exclude_guides || alias[0] == '!') {\n> +\t\t\tprintf_ln(_(\"'%s' is aliased to '%s'\"), cmd, alias);\n> +\t\t\tfree(alias);\n> +\t\t\texit(0);\n> +\t\t}\n\nI'm not sure I understand why exclude_guides is relevant. We check it\nbelow when we know that we _don't_ have an alias. Hrm. I guess you're\nusing it here as a proxy for \"git foo --help\" being used instead of \"git\nhelp foo\". The comment probably needs to spell out that exclude_guides\nis the same as your \"we were invoked as...\".\n\nI wonder if we could change the name of that option. It is an\nundocumented, hidden option that we use internally, so it should be OK\nto do so (or we could always add another one). That might prevent\nsomebody in the future from using --exclude-guides in more places and\nbreaking your assumption here.\n\n> +\t\t/*\n> +\t\t * Otherwise, we pretend that the command was \"git\n> +\t\t * word0 --help.\n> +\t\t */\n> +\t\tfprintf_ln(stderr, _(\"'%s' is aliased to '%s'\"), cmd, alias);\n> +\t\tcount = split_cmdline(alias, &argv);\n> +\t\tif (count < 0)\n> +\t\t\tdie(_(\"bad alias.%s string: %s\"), cmd,\n> +\t\t\t split_cmdline_strerror(count));\n> +\t\treturn alias;\n\nSo we split only to find argv[0] here. But then we don't return it. That\nworks because the split is done in place, meaning we must have inserted\na NUL in alias. That's sufficiently subtle that it might be worth\nspelling it out in a comment.\n\nWe don't need to free alias here as we do above, because we're passing\nit back. We should free argv, though, I think (not its elements, just\nthe array itself).\n\nUnfortunately the caller is going to leak our returned \"alias\", but I'm\nnot sure we can do much about it. I'm not overly concerned with the\nmemory, but it is going to trigger leak-checkers (and we're trying to\nquiet them down, not go the other way). I think it may be OK to overlook\nthat and just UNLEAK() it in cmd_help().\n\n-Peff\n"},{"id":"359489","messageId":"20181003021607.GB20553@sigill.intra.peff.net","threadId":"49428","inReplyTo":"20181001112107.28956-2-rv@rasmusvillemoes.dk","subject":"Re: [PATCH v2 2/3] git.c: handle_alias: prepend alias info when first argument is -h","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2018-10-03T02:16:07Z","receivedAt":"2018-10-03T02:18:21Z","isPatch":true,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Mon, Oct 01, 2018 at 01:21:06PM +0200, Rasmus Villemoes wrote:\n\n> Most git commands respond to -h anywhere in the command line, or at\n> least as a first and lone argument, by printing the usage\n> information. For aliases, we can provide a little more information that\n> might be useful in interpreting/understanding the following output by\n> prepending a line telling that the command is an alias, and for what.\n> \n> When one invokes a simple alias, such as \"cp = cherry-pick\"\n> with -h, this results in\n> \n> $ git cp -h\n> 'cp' is aliased to 'cherry-pick'\n> usage: git cherry-pick [] ...\n> ...\n> \n> When the alias consists of more than one word, this provides the\n> additional benefit of informing the user which options are implicit in\n> using the alias, e.g. with \"cp = cherry-pick -n\":\n> \n> $ git cp -h\n> 'cp' is aliased to 'cherry-pick -n'\n> usage: git cherry-pick [] ...\n> ...\n> \n> For shell commands, we cannot know how it responds to -h, but printing\n> this line to stderr should not hurt, and can help in figuring out what\n> is happening in a case like\n> \n> $ git sc -h\n> 'sc' is aliased to '!somecommand'\n> somecommand: invalid option '-h'\n\nNicely explained.\n\n> diff --git a/git.c b/git.c\n> index a6f4b44af5..0211c2d4c0 100644\n> --- a/git.c\n> +++ b/git.c\n> @@ -318,6 +318,9 @@ static int handle_alias(int *argcp, const char ***argv)\n> \talias_command = (*argv)[0];\n> \talias_string = alias_lookup(alias_command);\n> \tif (alias_string) {\n> +\t\tif (*argcp > 1 && !strcmp((*argv)[1], \"-h\"))\n> +\t\t\tfprintf_ln(stderr, _(\"'%s' is aliased to '%s'\"),\n> +\t\t\t\t alias_command, alias_string);\n> \t\tif (alias_string[0] == '!') {\n> \t\t\tstruct child_process child = CHILD_PROCESS_INIT;\n> \t\t\tint nongit_ok;\n\nAnd the implementation makes sense.\n\n-Peff\n"},{"id":"359490","messageId":"20181003021816.GC20553@sigill.intra.peff.net","threadId":"49428","inReplyTo":"20181001112107.28956-3-rv@rasmusvillemoes.dk","subject":"Re: [PATCH v2 3/3] git-help.txt: document \"git help cmd\" vs \"git cmd --help\" for aliases","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2018-10-03T02:18:17Z","receivedAt":"2018-10-03T02:18:21Z","isPatch":true,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Mon, Oct 01, 2018 at 01:21:07PM +0200, Rasmus Villemoes wrote:\n\n> This documents the existing behaviour of \"git help cmd\" when cmd is an\n> alias, as well as providing a hint to use the \"git cmd --help\" form to\n> be taken directly to the man page for the aliased command.\n\nGood idea.\n\n> diff --git a/Documentation/git-help.txt b/Documentation/git-help.txt\n> index 83d25d825a..37e85868fd 100644\n> --- a/Documentation/git-help.txt\n> +++ b/Documentation/git-help.txt\n> @@ -29,6 +29,10 @@ guide is brought up. The 'man' program is used by default for this\n> purpose, but this can be overridden by other options or configuration\n> variables.\n> \n> +If an alias is given, git prints a note explaining what it is an alias\n> +for on standard output. To get the manual page for the aliased\n> +command, use `git COMMAND --help`.\n\nFunny English: \"what it is an...\". Maybe:\n\n If an alias is given, git shows the definition of the alias on\n standard output. To get the manual page...\n\n\n-Peff\n"},{"id":"359496","messageId":"9ab3d69a-033a-e5a0-7459-c6ba8a2ec853@rasmusvillemoes.dk","threadId":"49428","inReplyTo":"20181003021358.GA20553@sigill.intra.peff.net","subject":"Re: [PATCH v2 1/3] help: redirect to aliased commands for \"git cmd --help\"","fromName":"Rasmus Villemoes","fromEmail":"rv@rasmusvillemoes.dk","sentAt":"2018-10-03T06:24:14Z","receivedAt":"2018-10-03T06:24:21Z","isPatch":true,"sender":{"key":"rv@rasmusvillemoes.dk","avatar":"https://avatars.githubusercontent.com/u/4375908?v=4"},"body":"On 2018-10-03 04:13, Jeff King wrote:\n>> +\t\t/*\n>> +\t\t * If we were invoked as \"git help cmd\", or cmd is an\n>> +\t\t * alias for a shell command, we inform the user what\n>> +\t\t * cmd is an alias for and do nothing else.\n>> +\t\t */\n>> +\t\tif (!exclude_guides || alias[0] == '!') {\n>> +\t\t\tprintf_ln(_(\"'%s' is aliased to '%s'\"), cmd, alias);\n>> +\t\t\tfree(alias);\n>> +\t\t\texit(0);\n>> +\t\t}\n> \n> I'm not sure I understand why exclude_guides is relevant. We check it\n> below when we know that we _don't_ have an alias. Hrm. I guess you're\n> using it here as a proxy for \"git foo --help\" being used instead of \"git\n> help foo\".\n\nExactly. Perhaps it's abusing the existing machinery, but I didn't know\nhow else to distinguish the two cases, and didn't feel like introducing\nanother way of passing on the exact same information.\n\n> The comment probably needs to spell out that exclude_guides\n> is the same as your \"we were invoked as...\".\n\nWill do. That will also make the string --exclude-guides (i.e., with a\ndash) appear in the comment, making it more likely to be found should\nanyone change when and how --exclude-guides is implied.\n\n> I wonder if we could change the name of that option. It is an\n> undocumented, hidden option that we use internally, so it should be OK\n> to do so (or we could always add another one). That might prevent\n> somebody in the future from using --exclude-guides in more places and\n> breaking your assumption here.\n\nPerhaps, but I think that's better left for a separate patch, if really\nnecessary even with the expanded comment.\n\n>> +\t\tcount = split_cmdline(alias, &argv);\n>> +\t\tif (count < 0)\n>> +\t\t\tdie(_(\"bad alias.%s string: %s\"), cmd,\n>> +\t\t\t split_cmdline_strerror(count));\n>> +\t\treturn alias;\n> \n> So we split only to find argv[0] here. But then we don't return it. That\n> works because the split is done in place, meaning we must have inserted\n> a NUL in alias. That's sufficiently subtle that it might be worth\n> spelling it out in a comment.\n\nOK, I actually had precisely\n\n+\t\t/*\n+\t\t * We use split_cmdline() to get the first word of the\n+\t\t * alias, to ensure that we use the same rules as when\n+\t\t * the alias is actually used. split_cmdline()\n+\t\t * modifies alias in-place.\n+\t\t */\n\nin v1, but thought it might be overly verbose. I'll put it back in.\n\n> We don't need to free alias here as we do above, because we're passing\n> it back. We should free argv, though, I think (not its elements, just\n> the array itself).\n\nYeah, I thought about this, and removing free(argv) was the last thing I\ndid before sending v1 - because we were going to leak alias anyway. I'm\nhappy to put it back in, along with...\n\n> Unfortunately the caller is going to leak our returned \"alias\", [...] I think it may be OK to overlook\n> that and just UNLEAK() it in cmd_help().\n\n...this. Except I'd rather do the UNLEAK in check_git_cmd (the\ndocumentation does say \"only from cmd_* functions or their direct\nhelpers\") to make it a more targeted annotation.\n\nThanks,\nRasmus\n"},{"id":"359497","messageId":"b5d0e881-d4b5-16e8-13df-46f9cb81f9c4@rasmusvillemoes.dk","threadId":"49428","inReplyTo":"20181003021816.GC20553@sigill.intra.peff.net","subject":"Re: [PATCH v2 3/3] git-help.txt: document \"git help cmd\" vs \"git cmd --help\" for aliases","fromName":"Rasmus Villemoes","fromEmail":"rv@rasmusvillemoes.dk","sentAt":"2018-10-03T06:25:20Z","receivedAt":"2018-10-03T06:25:24Z","isPatch":true,"sender":{"key":"rv@rasmusvillemoes.dk","avatar":"https://avatars.githubusercontent.com/u/4375908?v=4"},"body":"On 2018-10-03 04:18, Jeff King wrote:\n> On Mon, Oct 01, 2018 at 01:21:07PM +0200, Rasmus Villemoes wrote:\n> \n>> \n>> +If an alias is given, git prints a note explaining what it is an alias\n>> +for on standard output. To get the manual page for the aliased\n>> +command, use `git COMMAND --help`.\n> \n> Funny English: \"what it is an...\". Maybe:\n> \n> If an alias is given, git shows the definition of the alias on\n> standard output. To get the manual page...\n\nMuch better, thanks.\n\nRasmus\n"},{"id":"359498","messageId":"20181003070645.GA6019@sigill.intra.peff.net","threadId":"49428","inReplyTo":"9ab3d69a-033a-e5a0-7459-c6ba8a2ec853@rasmusvillemoes.dk","subject":"Re: [PATCH v2 1/3] help: redirect to aliased commands for \"git cmd --help\"","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2018-10-03T07:06:45Z","receivedAt":"2018-10-03T07:06:49Z","isPatch":true,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Wed, Oct 03, 2018 at 08:24:14AM +0200, Rasmus Villemoes wrote:\n\n> > The comment probably needs to spell out that exclude_guides\n> > is the same as your \"we were invoked as...\".\n> \n> Will do. That will also make the string --exclude-guides (i.e., with a\n> dash) appear in the comment, making it more likely to be found should\n> anyone change when and how --exclude-guides is implied.\n\nOK. I can live with that.\n\n> > So we split only to find argv[0] here. But then we don't return it. That\n> > works because the split is done in place, meaning we must have inserted\n> > a NUL in alias. That's sufficiently subtle that it might be worth\n> > spelling it out in a comment.\n> \n> OK, I actually had precisely\n> \n> +\t\t/*\n> +\t\t * We use split_cmdline() to get the first word of the\n> +\t\t * alias, to ensure that we use the same rules as when\n> +\t\t * the alias is actually used. split_cmdline()\n> +\t\t * modifies alias in-place.\n> +\t\t */\n> \n> in v1, but thought it might be overly verbose. I'll put it back in.\n\n:) That's perfect.\n\n> > We don't need to free alias here as we do above, because we're passing\n> > it back. We should free argv, though, I think (not its elements, just\n> > the array itself).\n> \n> Yeah, I thought about this, and removing free(argv) was the last thing I\n> did before sending v1 - because we were going to leak alias anyway. I'm\n> happy to put it back in, along with...\n\nThanks. I think this is different than \"alias\" because we really do leak\nit _here_, whereas alias lives on and can be UNLEAKed later.\n\n> > Unfortunately the caller is going to leak our returned \"alias\", [...] I think it may be OK to overlook\n> > that and just UNLEAK() it in cmd_help().\n> \n> ...this. Except I'd rather do the UNLEAK in check_git_cmd (the\n> documentation does say \"only from cmd_* functions or their direct\n> helpers\") to make it a more targeted annotation.\n\nYeah, I think that's fine. Thanks!\n\n-Peff\n"},{"id":"359507","messageId":"20181003114242.9858-1-rv@rasmusvillemoes.dk","threadId":"49428","inReplyTo":"20181001112107.28956-1-rv@rasmusvillemoes.dk","subject":"[PATCH v3 0/3] alias help tweaks","fromName":"Rasmus Villemoes","fromEmail":"rv@rasmusvillemoes.dk","sentAt":"2018-10-03T11:42:39Z","receivedAt":"2018-10-03T11:42:49Z","isPatch":true,"sender":{"key":"rv@rasmusvillemoes.dk","avatar":"https://avatars.githubusercontent.com/u/4375908?v=4"},"body":"v2: Added patches 2 and 3, made \"git cmd --help\" unconditionally (no\nconfig option, no delay) redirect to the aliased command's help,\npreserve pre-existing behaviour of the spelling \"git help cmd\".\n\nv3: Add some additional comments in patch 1 and avoid triggering leak\nchecker reports. Use better wording in patch 3.\n\nRasmus Villemoes (3):\n help: redirect to aliased commands for \"git cmd --help\"\n git.c: handle_alias: prepend alias info when first argument is -h\n git-help.txt: document \"git help cmd\" vs \"git cmd --help\" for aliases\n\n Documentation/git-help.txt | 4 ++++\n builtin/help.c | 34 +++++++++++++++++++++++++++++++---\n git.c | 3 +++\n 3 files changed, 38 insertions(+), 3 deletions(-)\n\n-- \n2.19.0\n\n"},{"id":"359508","messageId":"20181003114242.9858-2-rv@rasmusvillemoes.dk","threadId":"49428","inReplyTo":"20181003114242.9858-1-rv@rasmusvillemoes.dk","subject":"[PATCH v3 1/3] help: redirect to aliased commands for \"git cmd --help\"","fromName":"Rasmus Villemoes","fromEmail":"rv@rasmusvillemoes.dk","sentAt":"2018-10-03T11:42:40Z","receivedAt":"2018-10-03T11:42:51Z","isPatch":true,"sender":{"key":"rv@rasmusvillemoes.dk","avatar":"https://avatars.githubusercontent.com/u/4375908?v=4"},"body":"As discussed in the thread for v1 of this patch [1] [2], this changes the\nrules for \"git foo --help\" when foo is an alias.\n\n(0) When invoked as \"git help foo\", we continue to print the \"foo is\naliased to bar\" message and nothing else.\n\n(1) If foo is an alias for a shell command, print \"foo is aliased to\n!bar\" as usual.\n\n(2) Otherwise, break the alias string into words, and pretend that \"git\nword0 --help\" was called.\n\nAt least for me, getting the man page for git-cherry-pick directly with\n\"git cp --help\" is more useful (and how I expect an alias to behave)\nthan the short \"is aliased to\" notice. It is also consistent with\n\"--help\" generally providing more comprehensive help than \"-h\".\n\nI believe that printing the \"is aliased to\" message also in case (2) has\nvalue: Depending on pager setup, or if the user has help.format=web, the\nmessage is still present immediately above the prompt when the user\nquits the pager/returns to the terminal. That serves as an explanation\nfor why one was redirected to \"man git-cherry-pick\" from \"git cp\n--help\", and if cp is actually 'cherry-pick -n', it reminds the user\nthat using cp has some flag implicitly set before firing off the next\ncommand.\n\nIt also provides some useful info in case we end up erroring out, either\nin the \"bad alias string\" check, or in the \"No manual entry for gitbar\"\ncase.\n\n[1] https://public-inbox.org/git/20180926102636.30691-1-rv@rasmusvillemoes.dk/\n[2] https://public-inbox.org/git/20180926184914.GC30680@sigill.intra.peff.net/\n\nSigned-off-by: Rasmus Villemoes \n---\n builtin/help.c | 34 +++++++++++++++++++++++++++++++---\n 1 file changed, 31 insertions(+), 3 deletions(-)\n\ndiff --git a/builtin/help.c b/builtin/help.c\nindex 8d4f6dd301..e0e3fe62e9 100644\n--- a/builtin/help.c\n+++ b/builtin/help.c\n@@ -415,9 +415,37 @@ static const char *check_git_cmd(const char* cmd)\n \n \talias = alias_lookup(cmd);\n \tif (alias) {\n-\t\tprintf_ln(_(\"'%s' is aliased to '%s'\"), cmd, alias);\n-\t\tfree(alias);\n-\t\texit(0);\n+\t\tconst char **argv;\n+\t\tint count;\n+\n+\t\t/*\n+\t\t * handle_builtin() in git.c rewrites \"git cmd --help\"\n+\t\t * to \"git help --exclude-guides cmd\", so we can use\n+\t\t * exclude_guides to distinguish \"git cmd --help\" from\n+\t\t * \"git help cmd\". In the latter case, or if cmd is an\n+\t\t * alias for a shell command, just print the alias\n+\t\t * definition.\n+\t\t */\n+\t\tif (!exclude_guides || alias[0] == '!') {\n+\t\t\tprintf_ln(_(\"'%s' is aliased to '%s'\"), cmd, alias);\n+\t\t\tfree(alias);\n+\t\t\texit(0);\n+\t\t}\n+\t\t/*\n+\t\t * Otherwise, we pretend that the command was \"git\n+\t\t * word0 --help\". We use split_cmdline() to get the\n+\t\t * first word of the alias, to ensure that we use the\n+\t\t * same rules as when the alias is actually\n+\t\t * used. split_cmdline() modifies alias in-place.\n+\t\t */\n+\t\tfprintf_ln(stderr, _(\"'%s' is aliased to '%s'\"), cmd, alias);\n+\t\tcount = split_cmdline(alias, &argv);\n+\t\tif (count < 0)\n+\t\t\tdie(_(\"bad alias.%s string: %s\"), cmd,\n+\t\t\t split_cmdline_strerror(count));\n+\t\tfree(argv);\n+\t\tUNLEAK(alias);\n+\t\treturn alias;\n \t}\n \n \tif (exclude_guides)\n-- \n2.19.0\n\n"},{"id":"359509","messageId":"20181003114242.9858-3-rv@rasmusvillemoes.dk","threadId":"49428","inReplyTo":"20181003114242.9858-1-rv@rasmusvillemoes.dk","subject":"[PATCH v3 2/3] git.c: handle_alias: prepend alias info when first argument is -h","fromName":"Rasmus Villemoes","fromEmail":"rv@rasmusvillemoes.dk","sentAt":"2018-10-03T11:42:41Z","receivedAt":"2018-10-03T11:42:52Z","isPatch":true,"sender":{"key":"rv@rasmusvillemoes.dk","avatar":"https://avatars.githubusercontent.com/u/4375908?v=4"},"body":"Most git commands respond to -h anywhere in the command line, or at\nleast as a first and lone argument, by printing the usage\ninformation. For aliases, we can provide a little more information that\nmight be useful in interpreting/understanding the following output by\nprepending a line telling that the command is an alias, and for what.\n\nWhen one invokes a simple alias, such as \"cp = cherry-pick\"\nwith -h, this results in\n\n$ git cp -h\n'cp' is aliased to 'cherry-pick'\nusage: git cherry-pick [] ...\n...\n\nWhen the alias consists of more than one word, this provides the\nadditional benefit of informing the user which options are implicit in\nusing the alias, e.g. with \"cp = cherry-pick -n\":\n\n$ git cp -h\n'cp' is aliased to 'cherry-pick -n'\nusage: git cherry-pick [] ...\n...\n\nFor shell commands, we cannot know how it responds to -h, but printing\nthis line to stderr should not hurt, and can help in figuring out what\nis happening in a case like\n\n$ git sc -h\n'sc' is aliased to '!somecommand'\nsomecommand: invalid option '-h'\n\nSuggested-by: Jeff King \nSigned-off-by: Rasmus Villemoes \n---\n git.c | 3 +++\n 1 file changed, 3 insertions(+)\n\ndiff --git a/git.c b/git.c\nindex a6f4b44af5..0211c2d4c0 100644\n--- a/git.c\n+++ b/git.c\n@@ -318,6 +318,9 @@ static int handle_alias(int *argcp, const char ***argv)\n \talias_command = (*argv)[0];\n \talias_string = alias_lookup(alias_command);\n \tif (alias_string) {\n+\t\tif (*argcp > 1 && !strcmp((*argv)[1], \"-h\"))\n+\t\t\tfprintf_ln(stderr, _(\"'%s' is aliased to '%s'\"),\n+\t\t\t\t alias_command, alias_string);\n \t\tif (alias_string[0] == '!') {\n \t\t\tstruct child_process child = CHILD_PROCESS_INIT;\n \t\t\tint nongit_ok;\n-- \n2.19.0\n\n"},{"id":"359510","messageId":"20181003114242.9858-4-rv@rasmusvillemoes.dk","threadId":"49428","inReplyTo":"20181003114242.9858-1-rv@rasmusvillemoes.dk","subject":"[PATCH v3 3/3] git-help.txt: document \"git help cmd\" vs \"git cmd --help\" for aliases","fromName":"Rasmus Villemoes","fromEmail":"rv@rasmusvillemoes.dk","sentAt":"2018-10-03T11:42:42Z","receivedAt":"2018-10-03T11:42:53Z","isPatch":true,"sender":{"key":"rv@rasmusvillemoes.dk","avatar":"https://avatars.githubusercontent.com/u/4375908?v=4"},"body":"This documents the existing behaviour of \"git help cmd\" when cmd is an\nalias, as well as providing a hint to use the \"git cmd --help\" form to\nbe taken directly to the man page for the aliased command.\n\nSigned-off-by: Rasmus Villemoes \n---\n Documentation/git-help.txt | 4 ++++\n 1 file changed, 4 insertions(+)\n\ndiff --git a/Documentation/git-help.txt b/Documentation/git-help.txt\nindex 83d25d825a..86a6b42345 100644\n--- a/Documentation/git-help.txt\n+++ b/Documentation/git-help.txt\n@@ -29,6 +29,10 @@ guide is brought up. The 'man' program is used by default for this\n purpose, but this can be overridden by other options or configuration\n variables.\n \n+If an alias is given, git shows the definition of the alias on\n+standard output. To get the manual page for the aliased command, use\n+`git COMMAND --help`.\n+\n Note that `git --help ...` is identical to `git help ...` because the\n former is internally converted into the latter.\n \n-- \n2.19.0\n\n"},{"id":"359599","messageId":"20181004001005.GA28016@sigill.intra.peff.net","threadId":"49428","inReplyTo":"20181003114242.9858-1-rv@rasmusvillemoes.dk","subject":"Re: [PATCH v3 0/3] alias help tweaks","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2018-10-04T00:10:05Z","receivedAt":"2018-10-04T00:10:08Z","isPatch":true,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Wed, Oct 03, 2018 at 01:42:39PM +0200, Rasmus Villemoes wrote:\n\n> v2: Added patches 2 and 3, made \"git cmd --help\" unconditionally (no\n> config option, no delay) redirect to the aliased command's help,\n> preserve pre-existing behaviour of the spelling \"git help cmd\".\n> \n> v3: Add some additional comments in patch 1 and avoid triggering leak\n> checker reports. Use better wording in patch 3.\n\nThanks, v3 looks good to me!\n\n-Peff\n"},{"id":"359661","messageId":"xmqq8t3czty3.fsf@gitster-ct.c.googlers.com","threadId":"49428","inReplyTo":"20181003114242.9858-2-rv@rasmusvillemoes.dk","subject":"Re: [PATCH v3 1/3] help: redirect to aliased commands for \"git cmd --help\"","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2018-10-05T08:19:48Z","receivedAt":"2018-10-05T08:19:54Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Rasmus Villemoes writes:\n\n> As discussed in the thread for v1 of this patch [1] [2], this changes the\n> rules for \"git foo --help\" when foo is an alias.\n>\n> (0) When invoked as \"git help foo\", we continue to print the \"foo is\n> aliased to bar\" message and nothing else.\n>\n> (1) If foo is an alias for a shell command, print \"foo is aliased to\n> !bar\" as usual.\n>\n> (2) Otherwise, break the alias string into words, and pretend that \"git\n> word0 --help\" was called.\n>\n> At least for me, getting the man page for git-cherry-pick directly with\n> \"git cp --help\" is more useful (and how I expect an alias to behave)\n> than the short \"is aliased to\" notice. It is also consistent with\n> \"--help\" generally providing more comprehensive help than \"-h\".\n>\n> I believe that printing the \"is aliased to\" message also in case (2) has\n> value: Depending on pager setup, or if the user has help.format=web, the\n> message is still present immediately above the prompt when the user\n> quits the pager/returns to the terminal. That serves as an explanation\n> for why one was redirected to \"man git-cherry-pick\" from \"git cp\n> --help\", and if cp is actually 'cherry-pick -n', it reminds the user\n> that using cp has some flag implicitly set before firing off the next\n> command.\n>\n> It also provides some useful info in case we end up erroring out, either\n> in the \"bad alias string\" check, or in the \"No manual entry for gitbar\"\n> case.\n\nThese two paragraphs were misleading, because they sounded as if you\nwere lamenting that you were somehow forbidden from doing so even\nthough you believe doing it is the right thing.\n\nBut that is not what is happening. I think we should update the (2)\nabove to mention what you actually do in the code, perhaps like so:\n\n (2) Otherwise, show \"foo is aliased to bar\" to the standard\n error stream, and then break the alias string into words and\n pretend as if \"git word[0] --help\" were called. The former\n is necessary to help users when 'foo' is aliased to a\n command with an option (e.g. \"[alias] cp = cherry-pick -n\"),\n and hopefully remain visible when help.format=web is used,\n \"git bar --help\" errors out, or the manpage of \"git bar\" is\n short enough. It may not help if the help shows manpage on\n the terminal as usual, though.\n\nAs we explain why we show the alias information before going to the\nmanpage in the item itself and a brief discussion of pros-and-cons,\nwe can safely lose the \"I believe...\" paragraph, which looks\nsomewhat out of place in a log message.\n\nIt also is strange to count from (0); if the patchset is rerolled\nagain, I'd prefer to see these start counting from (1), in which\ncase this item will become (3).\n\n> [1] https://public-inbox.org/git/20180926102636.30691-1-rv@rasmusvillemoes.dk/\n> [2] https://public-inbox.org/git/20180926184914.GC30680@sigill.intra.peff.net/\n>\n> Signed-off-by: Rasmus Villemoes \n> ---\n> builtin/help.c | 34 +++++++++++++++++++++++++++++++---\n> 1 file changed, 31 insertions(+), 3 deletions(-)\n>\n> diff --git a/builtin/help.c b/builtin/help.c\n> index 8d4f6dd301..e0e3fe62e9 100644\n> --- a/builtin/help.c\n> +++ b/builtin/help.c\n> @@ -415,9 +415,37 @@ static const char *check_git_cmd(const char* cmd)\n> \n> \talias = alias_lookup(cmd);\n> \tif (alias) {\n> -\t\tprintf_ln(_(\"'%s' is aliased to '%s'\"), cmd, alias);\n> -\t\tfree(alias);\n> -\t\texit(0);\n> +\t\tconst char **argv;\n> +\t\tint count;\n> +\n> +\t\t/*\n> +\t\t * handle_builtin() in git.c rewrites \"git cmd --help\"\n> +\t\t * to \"git help --exclude-guides cmd\", so we can use\n> +\t\t * exclude_guides to distinguish \"git cmd --help\" from\n> +\t\t * \"git help cmd\". In the latter case, or if cmd is an\n> +\t\t * alias for a shell command, just print the alias\n> +\t\t * definition.\n> +\t\t */\n> +\t\tif (!exclude_guides || alias[0] == '!') {\n> +\t\t\tprintf_ln(_(\"'%s' is aliased to '%s'\"), cmd, alias);\n> +\t\t\tfree(alias);\n> +\t\t\texit(0);\n> +\t\t}\n> +\t\t/*\n> +\t\t * Otherwise, we pretend that the command was \"git\n> +\t\t * word0 --help\". We use split_cmdline() to get the\n> +\t\t * first word of the alias, to ensure that we use the\n> +\t\t * same rules as when the alias is actually\n> +\t\t * used. split_cmdline() modifies alias in-place.\n> +\t\t */\n> +\t\tfprintf_ln(stderr, _(\"'%s' is aliased to '%s'\"), cmd, alias);\n> +\t\tcount = split_cmdline(alias, &argv);\n> +\t\tif (count < 0)\n> +\t\t\tdie(_(\"bad alias.%s string: %s\"), cmd,\n> +\t\t\t split_cmdline_strerror(count));\n> +\t\tfree(argv);\n> +\t\tUNLEAK(alias);\n> +\t\treturn alias;\n> \t}\n> \n> \tif (exclude_guides)\n"},{"id":"359664","messageId":"5e79944d-e82f-f4c1-00ec-445121769f42@rasmusvillemoes.dk","threadId":"49428","inReplyTo":"xmqq8t3czty3.fsf@gitster-ct.c.googlers.com","subject":"Re: [PATCH v3 1/3] help: redirect to aliased commands for \"git cmd --help\"","fromName":"Rasmus Villemoes","fromEmail":"rv@rasmusvillemoes.dk","sentAt":"2018-10-05T10:22:32Z","receivedAt":"2018-10-05T10:22:37Z","isPatch":true,"sender":{"key":"rv@rasmusvillemoes.dk","avatar":"https://avatars.githubusercontent.com/u/4375908?v=4"},"body":"On 2018-10-05 10:19, Junio C Hamano wrote:\n> Rasmus Villemoes writes:\n> \n>>\n>> I believe that printing the \"is aliased to\" message also in case (2) has\n>> value: Depending on pager setup, or if the user has help.format=web, the\n>> message is still present immediately above the prompt when the user\n>> quits the pager/returns to the terminal. That serves as an explanation\n>> for why one was redirected to \"man git-cherry-pick\" from \"git cp\n>> --help\", and if cp is actually 'cherry-pick -n', it reminds the user\n>> that using cp has some flag implicitly set before firing off the next\n>> command.\n>>\n>> It also provides some useful info in case we end up erroring out, either\n>> in the \"bad alias string\" check, or in the \"No manual entry for gitbar\"\n>> case.\n> \n> These two paragraphs were misleading, because they sounded as if you\n> were lamenting that you were somehow forbidden from doing so even\n> though you believe doing it is the right thing.\n> \n> But that is not what is happening. I think we should update the (2)\n> above to mention what you actually do in the code, perhaps like so:\n\nYes, what I wrote was probably better placed below ---.\n\n> and hopefully remain visible when help.format=web is used,\n> \"git bar --help\" errors out, or the manpage of \"git bar\" is\n> short enough. It may not help if the help shows manpage on\n\nor, as in my case, the pager does not clear the terminal. I even think\nthat's the default behaviour (due to X in $LESS) - at least, I don't\nhave any magic in the environment or .gitconfig to achieve this. So it's\nnot visible while the man page is shown in the pager, but upon exit from\nthe pager.\n\n> It also is strange to count from (0); if the patchset is rerolled\n> again, I'd prefer to see these start counting from (1), in which\n> case this item will become (3).\n\nIf you prefer, I can send a v4.\n\nRasmus\n"},{"id":"359699","messageId":"xmqqr2h4wdaq.fsf@gitster-ct.c.googlers.com","threadId":"49428","inReplyTo":"5e79944d-e82f-f4c1-00ec-445121769f42@rasmusvillemoes.dk","subject":"Re: [PATCH v3 1/3] help: redirect to aliased commands for \"git cmd --help\"","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2018-10-05T16:47:41Z","receivedAt":"2018-10-05T16:47:47Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Rasmus Villemoes writes:\n\n>> It also is strange to count from (0); if the patchset is rerolled\n>> again, I'd prefer to see these start counting from (1), in which\n>> case this item will become (3).\n>\n> If you prefer, I can send a v4.\n\nSure, if you prefer, you can send a v4 for me to look at and queue.\n\nThanks.\n"},{"id":"359915","messageId":"20181009115909.16648-1-rv@rasmusvillemoes.dk","threadId":"49428","inReplyTo":"20181003114242.9858-1-rv@rasmusvillemoes.dk","subject":"[PATCH v4 0/3] alias help tweaks","fromName":"Rasmus Villemoes","fromEmail":"rv@rasmusvillemoes.dk","sentAt":"2018-10-09T11:59:06Z","receivedAt":"2018-10-09T11:59:17Z","isPatch":true,"sender":{"key":"rv@rasmusvillemoes.dk","avatar":"https://avatars.githubusercontent.com/u/4375908?v=4"},"body":"v2: Added patches 2 and 3, made \"git cmd --help\" unconditionally (no\nconfig option, no delay) redirect to the aliased command's help,\npreserve pre-existing behaviour of the spelling \"git help cmd\".\n\nv3: Add some additional comments in patch 1 and avoid triggering leak\nchecker reports. Use better wording in patch 3.\n\nv4: Reword commit log in patch 1.\n\nRasmus Villemoes (3):\n help: redirect to aliased commands for \"git cmd --help\"\n git.c: handle_alias: prepend alias info when first argument is -h\n git-help.txt: document \"git help cmd\" vs \"git cmd --help\" for aliases\n\n Documentation/git-help.txt | 4 ++++\n builtin/help.c | 34 +++++++++++++++++++++++++++++++---\n git.c | 3 +++\n 3 files changed, 38 insertions(+), 3 deletions(-)\n\n-- \n2.19.1.4.g721af0fda3\n\n"},{"id":"359916","messageId":"20181009115909.16648-2-rv@rasmusvillemoes.dk","threadId":"49428","inReplyTo":"20181009115909.16648-1-rv@rasmusvillemoes.dk","subject":"[PATCH v4 1/3] help: redirect to aliased commands for \"git cmd --help\"","fromName":"Rasmus Villemoes","fromEmail":"rv@rasmusvillemoes.dk","sentAt":"2018-10-09T11:59:07Z","receivedAt":"2018-10-09T11:59:19Z","isPatch":true,"sender":{"key":"rv@rasmusvillemoes.dk","avatar":"https://avatars.githubusercontent.com/u/4375908?v=4"},"body":"As discussed in the thread for v1 of this patch [1] [2], this changes the\nrules for \"git foo --help\" when foo is an alias.\n\n(1) When invoked as \"git help foo\", we continue to print the \"foo is\naliased to bar\" message and nothing else.\n\n(2) If foo is an alias for a shell command, print \"foo is aliased to\n!bar\" as usual.\n\n(3) Otherwise, print \"foo is aliased to bar\" to the standard error\nstream, and then break the alias string into words and pretend as if\n\"git word[0] --help\" were called.\n\nGetting the man page for git-cherry-pick directly with \"git cp --help\"\nis consistent with \"--help\" generally providing more comprehensive help\nthan \"-h\". Printing the alias definition to stderr means that in certain\ncases (e.g. if help.format=web or if the pager uses an alternate screen\nand does not clear the terminal), one has\n\n'cp' is aliased to 'cherry-pick -n'\n\nabove the prompt when one returns to the terminal/quits the pager, which\nis a useful reminder that using 'cp' has some flag implicitly set. There\nare cases where this information vanishes or gets scrolled\naway, but being printed to stderr, it should never hurt.\n\n[1] https://public-inbox.org/git/20180926102636.30691-1-rv@rasmusvillemoes.dk/\n[2] https://public-inbox.org/git/20180926184914.GC30680@sigill.intra.peff.net/\n\nSigned-off-by: Rasmus Villemoes \n---\n builtin/help.c | 34 +++++++++++++++++++++++++++++++---\n 1 file changed, 31 insertions(+), 3 deletions(-)\n\ndiff --git a/builtin/help.c b/builtin/help.c\nindex 8d4f6dd301..e0e3fe62e9 100644\n--- a/builtin/help.c\n+++ b/builtin/help.c\n@@ -415,9 +415,37 @@ static const char *check_git_cmd(const char* cmd)\n \n \talias = alias_lookup(cmd);\n \tif (alias) {\n-\t\tprintf_ln(_(\"'%s' is aliased to '%s'\"), cmd, alias);\n-\t\tfree(alias);\n-\t\texit(0);\n+\t\tconst char **argv;\n+\t\tint count;\n+\n+\t\t/*\n+\t\t * handle_builtin() in git.c rewrites \"git cmd --help\"\n+\t\t * to \"git help --exclude-guides cmd\", so we can use\n+\t\t * exclude_guides to distinguish \"git cmd --help\" from\n+\t\t * \"git help cmd\". In the latter case, or if cmd is an\n+\t\t * alias for a shell command, just print the alias\n+\t\t * definition.\n+\t\t */\n+\t\tif (!exclude_guides || alias[0] == '!') {\n+\t\t\tprintf_ln(_(\"'%s' is aliased to '%s'\"), cmd, alias);\n+\t\t\tfree(alias);\n+\t\t\texit(0);\n+\t\t}\n+\t\t/*\n+\t\t * Otherwise, we pretend that the command was \"git\n+\t\t * word0 --help\". We use split_cmdline() to get the\n+\t\t * first word of the alias, to ensure that we use the\n+\t\t * same rules as when the alias is actually\n+\t\t * used. split_cmdline() modifies alias in-place.\n+\t\t */\n+\t\tfprintf_ln(stderr, _(\"'%s' is aliased to '%s'\"), cmd, alias);\n+\t\tcount = split_cmdline(alias, &argv);\n+\t\tif (count < 0)\n+\t\t\tdie(_(\"bad alias.%s string: %s\"), cmd,\n+\t\t\t split_cmdline_strerror(count));\n+\t\tfree(argv);\n+\t\tUNLEAK(alias);\n+\t\treturn alias;\n \t}\n \n \tif (exclude_guides)\n-- \n2.19.1.4.g721af0fda3\n\n"},{"id":"359917","messageId":"20181009115909.16648-3-rv@rasmusvillemoes.dk","threadId":"49428","inReplyTo":"20181009115909.16648-1-rv@rasmusvillemoes.dk","subject":"[PATCH v4 2/3] git.c: handle_alias: prepend alias info when first argument is -h","fromName":"Rasmus Villemoes","fromEmail":"rv@rasmusvillemoes.dk","sentAt":"2018-10-09T11:59:08Z","receivedAt":"2018-10-09T11:59:20Z","isPatch":true,"sender":{"key":"rv@rasmusvillemoes.dk","avatar":"https://avatars.githubusercontent.com/u/4375908?v=4"},"body":"Most git commands respond to -h anywhere in the command line, or at\nleast as a first and lone argument, by printing the usage\ninformation. For aliases, we can provide a little more information that\nmight be useful in interpreting/understanding the following output by\nprepending a line telling that the command is an alias, and for what.\n\nWhen one invokes a simple alias, such as \"cp = cherry-pick\"\nwith -h, this results in\n\n$ git cp -h\n'cp' is aliased to 'cherry-pick'\nusage: git cherry-pick [] ...\n...\n\nWhen the alias consists of more than one word, this provides the\nadditional benefit of informing the user which options are implicit in\nusing the alias, e.g. with \"cp = cherry-pick -n\":\n\n$ git cp -h\n'cp' is aliased to 'cherry-pick -n'\nusage: git cherry-pick [] ...\n...\n\nFor shell commands, we cannot know how it responds to -h, but printing\nthis line to stderr should not hurt, and can help in figuring out what\nis happening in a case like\n\n$ git sc -h\n'sc' is aliased to '!somecommand'\nsomecommand: invalid option '-h'\n\nSuggested-by: Jeff King \nSigned-off-by: Rasmus Villemoes \n---\n git.c | 3 +++\n 1 file changed, 3 insertions(+)\n\ndiff --git a/git.c b/git.c\nindex a6f4b44af5..0211c2d4c0 100644\n--- a/git.c\n+++ b/git.c\n@@ -318,6 +318,9 @@ static int handle_alias(int *argcp, const char ***argv)\n \talias_command = (*argv)[0];\n \talias_string = alias_lookup(alias_command);\n \tif (alias_string) {\n+\t\tif (*argcp > 1 && !strcmp((*argv)[1], \"-h\"))\n+\t\t\tfprintf_ln(stderr, _(\"'%s' is aliased to '%s'\"),\n+\t\t\t\t alias_command, alias_string);\n \t\tif (alias_string[0] == '!') {\n \t\t\tstruct child_process child = CHILD_PROCESS_INIT;\n \t\t\tint nongit_ok;\n-- \n2.19.1.4.g721af0fda3\n\n"},{"id":"359918","messageId":"20181009115909.16648-4-rv@rasmusvillemoes.dk","threadId":"49428","inReplyTo":"20181009115909.16648-1-rv@rasmusvillemoes.dk","subject":"[PATCH v4 3/3] git-help.txt: document \"git help cmd\" vs \"git cmd --help\" for aliases","fromName":"Rasmus Villemoes","fromEmail":"rv@rasmusvillemoes.dk","sentAt":"2018-10-09T11:59:09Z","receivedAt":"2018-10-09T11:59:21Z","isPatch":true,"sender":{"key":"rv@rasmusvillemoes.dk","avatar":"https://avatars.githubusercontent.com/u/4375908?v=4"},"body":"This documents the existing behaviour of \"git help cmd\" when cmd is an\nalias, as well as providing a hint to use the \"git cmd --help\" form to\nbe taken directly to the man page for the aliased command.\n\nSigned-off-by: Rasmus Villemoes \n---\n Documentation/git-help.txt | 4 ++++\n 1 file changed, 4 insertions(+)\n\ndiff --git a/Documentation/git-help.txt b/Documentation/git-help.txt\nindex 83d25d825a..86a6b42345 100644\n--- a/Documentation/git-help.txt\n+++ b/Documentation/git-help.txt\n@@ -29,6 +29,10 @@ guide is brought up. The 'man' program is used by default for this\n purpose, but this can be overridden by other options or configuration\n variables.\n \n+If an alias is given, git shows the definition of the alias on\n+standard output. To get the manual page for the aliased command, use\n+`git COMMAND --help`.\n+\n Note that `git --help ...` is identical to `git help ...` because the\n former is internally converted into the latter.\n \n-- \n2.19.1.4.g721af0fda3\n\n"},{"id":"360266","messageId":"xmqq1s8vetv2.fsf@gitster-ct.c.googlers.com","threadId":"49428","inReplyTo":"20181009115909.16648-1-rv@rasmusvillemoes.dk","subject":"Re: [PATCH v4 0/3] alias help tweaks","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2018-10-12T03:17:37Z","receivedAt":"2018-10-12T03:17:42Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Rasmus Villemoes writes:\n\n> v2: Added patches 2 and 3, made \"git cmd --help\" unconditionally (no\n> config option, no delay) redirect to the aliased command's help,\n> preserve pre-existing behaviour of the spelling \"git help cmd\".\n>\n> v3: Add some additional comments in patch 1 and avoid triggering leak\n> checker reports. Use better wording in patch 3.\n>\n> v4: Reword commit log in patch 1.\n\nSorry for failing to point it out and let the style carried over to\nv4, but the above is insufficient for a cover latter. Those who\nmissed an earlier round has no clue what these patches are about,\nand there is not even a pointer to find an earlier discussion in the\nlist archive.\n\nI think the patches are good with the rounds of reviews it went\nthrough, so let's merge it to 'next'. Here is what I plan to start\nthe merge message of the series:\n\n \"git cmd --help\" when \"cmd\" is aliased used to only say \"cmd is\n aliased to ...\". Now it shows that to the standard error stream\n and runs \"git $cmd --help\" where $cmd is the first word of the\n alias expansion.\n\nPlease do the cover-letter better next time.\n\nThanks.\n\n>\n> Rasmus Villemoes (3):\n> help: redirect to aliased commands for \"git cmd --help\"\n> git.c: handle_alias: prepend alias info when first argument is -h\n> git-help.txt: document \"git help cmd\" vs \"git cmd --help\" for aliases\n>\n> Documentation/git-help.txt | 4 ++++\n> builtin/help.c | 34 +++++++++++++++++++++++++++++++---\n> git.c | 3 +++\n> 3 files changed, 38 insertions(+), 3 deletions(-)\n"}]}