{"thread":{"id":"57638","subject":"[PATCH v2] cli: add -v and -h shorthands","startedAt":"2022-03-30T19:12:10Z","lastAt":"2022-04-04T21:23:46Z","messageCount":11,"participants":["Garrit Franke","Junio C Hamano","Ævar Arnfjörð Bjarmason"],"isPatch":true,"patchVersion":2,"patchTotal":null},"messages":[{"id":"452692","messageId":"20220330190956.21447-1-garrit@slashdev.space","threadId":"57638","inReplyTo":null,"subject":"[PATCH v2] cli: add -v and -h shorthands","fromName":"Garrit Franke","fromEmail":"garrit@slashdev.space","sentAt":"2022-03-30T19:09:56Z","receivedAt":"2022-03-30T19:12:10Z","isPatch":true,"sender":{"key":"garrit@slashdev.space","avatar":"https://avatars.githubusercontent.com/u/32395585?v=4"},"body":"Change the behavior of \"git -v\" to be synonymous with \"--version\" /\n\"version\", and \"git -h\" to be synonymous with \"--help\", but not \"help\".\n\nThese shorthands both display the \"unknown option\" message. Following\nthis change, \"-v\" displays the version, and \"-h\" displays the help text\nof the \"git\" command.\n\nIt should be noted that the \"-v\" shorthand could be misinterpreted by\nthe user to mean \"verbose\" instead of \"version\", since some sub-commands\nmake use of it in this context. The top-level \"git\" command does not\nhave a \"verbose\" flag, so it's safe to introduce this shorthand\nunambiguously.\n\nSigned-off-by: Garrit Franke \n---\n\nOn Wed, Mar 30 2022, Ævar Arnfjörð Bjarmason wrote:\n\n> On a second reading I see that there's an implied \"change the behavior\n> to ...\" there.\n\nInteresting, I haven't yet thought of it that way. I tried to be as\nprecise as possible this time. :)\n\n> The translation files are updated by a process that the translation\n> teams(s) use, see po/README.md. I think changing this from under them\n> is probably more disruptive than not.\n\nThis doc slipped past me. Thanks!\n\n> nit: minimize the diff here perhaps by keeping the existing line, and\n> doing -h or -v on a new line? Your indentation here is also off.\n\nWhoops, the indentation looked fine in my editor with a tab-width of\nfour. I'll make sure to review the patch more carefully next time!\n\n> FWIW I have an existing branch (unsubmitted) at\n> https://github.com/avar/git/tree/avar/parse-options-h-3 where I added\n> some tests for \"git cmd -h\" behavior, which seems to pass with this\n> change (not unexpected, as this is for the top-level command).\n\nDo you think it makes sense to add tests for this behavior as well? I\noriginally refrained from adding them mainly due to lack of experience\nin the project, but I'd be happy to add some if necessary.\n\nThanks\nGarrit\n\n Documentation/git.txt | 4 +++-\n git.c | 12 +++++++++---\n t/t0012-help.sh | 2 +-\n 3 files changed, 13 insertions(+), 5 deletions(-)\n\ndiff --git a/Documentation/git.txt b/Documentation/git.txt\nindex 13f83a2..302607a 100644\n--- a/Documentation/git.txt\n+++ b/Documentation/git.txt\n@@ -9,7 +9,7 @@ git - the stupid content tracker\n SYNOPSIS\n --------\n [verse]\n-'git' [--version] [--help] [-C ] [-c =]\n+'git' [-v | --version] [-h | --help] [-C ] [-c =]\n [--exec-path[=]] [--html-path] [--man-path] [--info-path]\n [-p|--paginate|-P|--no-pager] [--no-replace-objects] [--bare]\n [--git-dir=] [--work-tree=] [--namespace=]\n@@ -39,6 +39,7 @@ or https://git-scm.com/docs.\n \n OPTIONS\n -------\n+-v::\n --version::\n \tPrints the Git suite version that the 'git' program came from.\n +\n@@ -46,6 +47,7 @@ This option is internally converted to `git version ...` and accepts\n the same options as the linkgit:git-version[1] command. If `--help` is\n also given, it takes precedence over `--version`.\n \n+-h::\n --help::\n \tPrints the synopsis and a list of the most commonly used\n \tcommands. If the option `--all` or `-a` is given then all\ndiff --git a/git.c b/git.c\nindex a25940d..024d463 100644\n--- a/git.c\n+++ b/git.c\n@@ -25,7 +25,7 @@ struct cmd_struct {\n };\n \n const char git_usage_string[] =\n-\tN_(\"git [--version] [--help] [-C ] [-c =]\\n\"\n+\tN_(\"git [-v | --version] [-h | --help] [-C ] [-c =]\\n\"\n \t \" [--exec-path[=]] [--html-path] [--man-path] [--info-path]\\n\"\n \t \" [-p | --paginate | -P | --no-pager] [--no-replace-objects] [--bare]\\n\"\n \t \" [--git-dir=] [--work-tree=] [--namespace=]\\n\"\n@@ -146,7 +146,8 @@ static int handle_options(const char ***argv, int *argc, int *envchanged)\n \t\t * commands can be written with \"--\" prepended\n \t\t * to make them look like flags.\n \t\t */\n-\t\tif (!strcmp(cmd, \"--help\") || !strcmp(cmd, \"--version\"))\n+\t\tif (!strcmp(cmd, \"--help\") || !strcmp(cmd, \"--version\") ||\n+\t\t !strcmp(cmd, \"-h\") || !strcmp(cmd, \"-v\"))\n \t\t\tbreak;\n \n \t\t/*\n@@ -893,7 +894,12 @@ int cmd_main(int argc, const char **argv)\n \thandle_options(&argv, &argc, NULL);\n \tif (argc > 0) {\n \t\t/* translate --help and --version into commands */\n-\t\tskip_prefix(argv[0], \"--\", &argv[0]);\n+\t\tif (!strcmp(\"-v\", argv[0]))\n+\t\t\targv[0] = \"version\";\n+\t\telse if (!strcmp(\"-h\", argv[0]))\n+\t\t\targv[0] = \"help\";\n+\t\telse\n+\t\t\tskip_prefix(argv[0], \"--\", &argv[0]);\n \t} else {\n \t\t/* The user didn't specify a command; give them help */\n \t\tcommit_pager_choice();\ndiff --git a/t/t0012-help.sh b/t/t0012-help.sh\nindex 6c3e1f7..6c33a43 100755\n--- a/t/t0012-help.sh\n+++ b/t/t0012-help.sh\n@@ -181,7 +181,7 @@ for cmd in git \"git help\"\n do\n \ttest_expect_success \"'$cmd' section spacing\" '\n \t\ttest_section_spacing_trailer git help <<-\\EOF &&\n-\t\tusage: git [--version] [--help] [-C ] [-c =]\n+\t\tusage: git [-v | --version] [-h | --help] [-C ] [-c =]\n \n \t\tThese are common Git commands used in various situations:\n \n-- \n2.35.1\n\n"},{"id":"452707","messageId":"xmqq5ynv6rb4.fsf@gitster.g","threadId":"57638","inReplyTo":"20220330190956.21447-1-garrit@slashdev.space","subject":"Re: [PATCH v2] cli: add -v and -h shorthands","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2022-03-30T21:53:03Z","receivedAt":"2022-03-30T21:53:09Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Garrit Franke writes:\n\n> Change the behavior of \"git -v\" to be synonymous with \"--version\" /\n> \"version\", and \"git -h\" to be synonymous with \"--help\", but not \"help\".\n>\n> These shorthands both display the \"unknown option\" message. Following\n> this change, \"-v\" displays the version, and \"-h\" displays the help text\n> of the \"git\" command.\n\nSorry, but it is unclear why it is a good thing.\n\n> It should be noted that the \"-v\" shorthand could be misinterpreted by\n> the user to mean \"verbose\" instead of \"version\", since some sub-commands\n> make use of it in this context. The top-level \"git\" command does not\n> have a \"verbose\" flag, so it's safe to introduce this shorthand\n> unambiguously.\n\nAgain, it might be safe right now, but it also closes the door for\nintroducing global \"verbose\" option. What in exchange are we\ngaining? Are these short options worth it?\n\nI am not convinced.\n\n"},{"id":"452719","messageId":"fb915b91-ead2-ac35-4431-ad35674da463@slashdev.space","threadId":"57638","inReplyTo":"xmqq5ynv6rb4.fsf@gitster.g","subject":"Re: [PATCH v2] cli: add -v and -h shorthands","fromName":"Garrit Franke","fromEmail":"garrit@slashdev.space","sentAt":"2022-03-30T22:50:56Z","receivedAt":"2022-03-30T22:51:21Z","isPatch":true,"sender":{"key":"garrit@slashdev.space","avatar":"https://avatars.githubusercontent.com/u/32395585?v=4"},"body":"On Wed, Mar 30 2022, Junio C Hamano wrote:\n\n> Sorry, but it is unclear why it is a good thing.\n\nMy main motivation behind this change was a standardized user experience \nacross tools. Many users use these shorthands out of habit to get an \noverview of a program. Seeing the command fail and having to retype it \nin a longer form creates unnecessary friction between the user and the \nprogram.\n\n > Again, it might be safe right now, but it also closes the door for\n > introducing global \"verbose\" option. What in exchange are we\n > gaining? Are these short options worth it?\n\nI definitely see your concerns. Ultimately it's a question of which of \nthe two flags would be more convinient to have as a shorthand. As stated \nabove, users unfamiliar to the software arguably expect to see the \nversion number printed when using this flag. A user who seeks more \nverbose output is probably more familiar with the options, so they are \nmore likely to know they have to use the longer \"--verbose\" form.\n\nThanks\nGarrit\n"},{"id":"452726","messageId":"220331.86tubfrngz.gmgdl@evledraar.gmail.com","threadId":"57638","inReplyTo":"fb915b91-ead2-ac35-4431-ad35674da463@slashdev.space","subject":"Re: [PATCH v2] cli: add -v and -h shorthands","fromName":"Ævar Arnfjörð Bjarmason","fromEmail":"avarab@gmail.com","sentAt":"2022-03-31T00:07:06Z","receivedAt":"2022-03-31T00:10:34Z","isPatch":true,"sender":{"key":"avarab@gmail.com","avatar":"https://avatars.githubusercontent.com/u/45301?v=4"},"body":"\nOn Thu, Mar 31 2022, Garrit Franke wrote:\n\n> On Wed, Mar 30 2022, Junio C Hamano wrote:\n>\n>> Sorry, but it is unclear why it is a good thing.\n>\n> My main motivation behind this change was a standardized user\n> experience across tools. Many users use these shorthands out of habit\n> to get an overview of a program. Seeing the command fail and having to\n> retype it in a longer form creates unnecessary friction between the\n> user and the program.\n\nI think this is a good trade-off in this case. I.e. -v and -h are\ncommonly understood.\n\n>> Again, it might be safe right now, but it also closes the door for\n>> introducing global \"verbose\" option. What in exchange are we\n>> gaining? Are these short options worth it?\n>\n> I definitely see your concerns. Ultimately it's a question of which of\n> the two flags would be more convinient to have as a shorthand. As\n> stated above, users unfamiliar to the software arguably expect to see\n> the version number printed when using this flag. A user who seeks more \n> verbose output is probably more familiar with the options, so they are\n> more likely to know they have to use the longer \"--verbose\" form.\n\nThis was somewhat discussed in/around\nhttps://lore.kernel.org/git/87zgs593ja.fsf@evledraar.gmail.com/,\ni.e. there I was arguing the counter-point, that we should have things\nlike \"git --no-progress subcmd \", rather than just \"git subcmd\n--no-progress \".\n\nBut I think the alternative won the day (at least in that commit-graph\ncase), and in retrospect I think it was the right call for our UI in\ngeneral.\n\nI still think it makes sense for git to understand a thing like\n--object-format at the top-level, and maybe/probably --progress, but\n--verbose is probably too confusing. I.e. it would imply verbose output\nfor all commands (which they're much less likely to have/provide than\nthe other two).\n"},{"id":"452791","messageId":"f3935840-e2a0-953e-0e7c-ac921d414ddc@slashdev.space","threadId":"57638","inReplyTo":"220331.86tubfrngz.gmgdl@evledraar.gmail.com","subject":"Re: [PATCH v2] cli: add -v and -h shorthands","fromName":"Garrit Franke","fromEmail":"garrit@slashdev.space","sentAt":"2022-03-31T13:08:12Z","receivedAt":"2022-03-31T13:08:43Z","isPatch":true,"sender":{"key":"garrit@slashdev.space","avatar":"https://avatars.githubusercontent.com/u/32395585?v=4"},"body":"On 31.03.22 02:07, Ævar Arnfjörð Bjarmason wrote:\n> \n> On Thu, Mar 31 2022, Garrit Franke wrote:\n> \n>> On Wed, Mar 30 2022, Junio C Hamano wrote:\n>>\n>>> Sorry, but it is unclear why it is a good thing.\n>>\n>> My main motivation behind this change was a standardized user\n>> experience across tools. Many users use these shorthands out of habit\n>> to get an overview of a program. Seeing the command fail and having to\n>> retype it in a longer form creates unnecessary friction between the\n>> user and the program.\n> \n> I think this is a good trade-off in this case. I.e. -v and -h are\n> commonly understood.\n\nAn interesting observation I just made is that curl [0] uses both\n\"--verbose\" and \"--version\" on the top level [1][2] including \nshorthands. \"-v\" corresponds to \"verbose\", \"-V\" corresponds to \"version.\n\nNot that I'm a fan of this clutter, but it's a possible path to go down \nif we actually needed a second shorthand using this letter.\n\n[0]: https://github.com/curl/curl\n[1]:\nhttps://github.com/curl/curl/blob/master/docs/cmdline-opts/version.d\n[2]:\nhttps://github.com/curl/curl/blob/master/docs/cmdline-opts/verbose.d\n\n\n"},{"id":"452831","messageId":"xmqqsfqx28dv.fsf@gitster.g","threadId":"57638","inReplyTo":"f3935840-e2a0-953e-0e7c-ac921d414ddc@slashdev.space","subject":"Re: [PATCH v2] cli: add -v and -h shorthands","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2022-03-31T20:07:40Z","receivedAt":"2022-03-31T20:07:48Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Garrit Franke writes:\n\n> On 31.03.22 02:07, Ævar Arnfjörð Bjarmason wrote:\n>\n>> I think this is a good trade-off in this case. I.e. -v and -h are\n>> commonly understood.\n>\n> An interesting observation I just made is that curl [0] uses both\n> \"--verbose\" and \"--version\" on the top level [1][2] including\n> shorthands. \"-v\" corresponds to \"verbose\", \"-V\" corresponds to\n> \"version.\n>\n> Not that I'm a fan of this clutter, but it's a possible path to go\n> down if we actually needed a second shorthand using this letter.\n\nDo you mean you want to use \"-V\" for version, instead of the \"-v\"\nused in the patch, so that \"-v\" can be left for \"--verbose\"?\n\nI am not sure consistency with whom we are aiming for anymore with\nthat mixed to the proposal X-<.\n\n> const char git_usage_string[] =\n> -\tN_(\"git [--version] [--help] [-C ] [-c =]\\n\"\n> +\tN_(\"git [-v | --version] [-h | --help] [-C ] [-c =]\\n\"\n> \t \" [--exec-path[=]] [--html-path] [--man-path] [--info-path]\\n\"\n> \t \" [-p | --paginate | -P | --no-pager] [--no-replace-objects] [--bare]\\n\"\n> \t \" [--git-dir=] [--work-tree=] [--namespace=]\\n\"\n\nThis is an improvement in that the first line that used to be\nunusually shorter now becomes comparable length to other lines ;-)\n\n> @@ -146,7 +146,8 @@ static int handle_options(const char ***argv, int *argc, int *envchanged)\n> \t\t * commands can be written with \"--\" prepended\n> \t\t * to make them look like flags.\n> \t\t */\n> -\t\tif (!strcmp(cmd, \"--help\") || !strcmp(cmd, \"--version\"))\n> +\t\tif (!strcmp(cmd, \"--help\") || !strcmp(cmd, \"--version\") ||\n> +\t\t !strcmp(cmd, \"-h\") || !strcmp(cmd, \"-v\"))\n> \t\t\tbreak;\n\nOK.\n\n> @@ -893,7 +894,12 @@ int cmd_main(int argc, const char **argv)\n> \thandle_options(&argv, &argc, NULL);\n> \tif (argc > 0) {\n> \t\t/* translate --help and --version into commands */\n> -\t\tskip_prefix(argv[0], \"--\", &argv[0]);\n> +\t\tif (!strcmp(\"-v\", argv[0]))\n> +\t\t\targv[0] = \"version\";\n> +\t\telse if (!strcmp(\"-h\", argv[0]))\n> +\t\t\targv[0] = \"help\";\n> +\t\telse\n> +\t\t\tskip_prefix(argv[0], \"--\", &argv[0]);\n\nI find this unnecessarily hard to read.\n\n (Side note) A tip for reviewers. Be suspicious of any change\n that adds new things _in front_ of existing sequence. Question\n if there is a good justification for it. If there isn't, see if\n it makes it better if you instead append the new stuff to\n existing sequence. If neither results in satisfying code,\n perhaps it is good time to totally rewrite it to make both\n existing and new stuff fit in the flow.\n\nThe original was in a sense a bit sloppy to strip \"--\" from anything\nthat begins with \"--\", when we only care about \"--verbose\" and\n\"--help\" and nothing else (granted, handle_options() would barf when\nargv[0] begins with \"--\" and is not one of these two, so the\nsloppiness does not make a difference in practice).\n\nIf we accept the same kind of sloppiness, perhaps\n\n\t\tif (skip_prefix(argv[0], \"--\", &argv[0]))\n \t; /* removed \"--\" from \"--help\" and \"--version\" */\n\t\telse if (argv[0][0] == '-')\n \targv[0] = argv[0][1] == 'v' ? \"version\" : \"help\";\n \t\nwould make the new side match the existing one better, but I would\nnot necessarily recommend it.\n\nWe may want to be a bit more explicit and readable, by spelling out\nthe expectation, i.e.\n\n\t\tif (!strcmp(\"--version\", argv[0]) || !strcmp(\"-v\", argv[0]))\n\t\t\targv[0] = \"version\";\n\t\telse if (!strcmp(\"--help\", argv[0]) || !strcmp(\"-h\", argv[0]))\n\t\t\targv[0] = \"help\"; \n\nThis makes it clear that these two pseudo-commands, spelled with a\ndash in front and stand for other commands, are the only thing we\ncare about and what their accepted spelling are.\n\nHmm?\n"},{"id":"452837","messageId":"20220331212709.36036-1-garrit@slashdev.space","threadId":"57638","inReplyTo":"20220330190956.21447-1-garrit@slashdev.space","subject":"[PATCH v3] cli: add -v and -h shorthands","fromName":"Garrit Franke","fromEmail":"garrit@slashdev.space","sentAt":"2022-03-31T21:27:09Z","receivedAt":"2022-03-31T21:28:12Z","isPatch":true,"sender":{"key":"garrit@slashdev.space","avatar":"https://avatars.githubusercontent.com/u/32395585?v=4"},"body":"Change the behavior of \"git -v\" to be synonymous with \"--version\" /\n\"version\", and \"git -h\" to be synonymous with \"--help\", but not \"help\".\n\nThese shorthands both display the \"unknown option\" message. Following\nthis change, \"-v\" displays the version, and \"-h\" displays the help text\nof the \"git\" command.\n\nIt should be noted that the \"-v\" shorthand could be misinterpreted by\nthe user to mean \"verbose\" instead of \"version\", since some sub-commands\nmake use of it in this context. The top-level \"git\" command does not\nhave a \"verbose\" flag, so it's safe to introduce this shorthand\nunambiguously.\n\nSigned-off-by: Garrit Franke \n---\nOn 31.03.22 22:07, Junio C Hamano wrote:\n>> Not that I'm a fan of this clutter, but it's a possible path to go\n>> down if we actually needed a second shorthand using this letter.\n> \n> Do you mean you want to use \"-V\" for version, instead of the \"-v\"\n> used in the patch, so that \"-v\" can be left for \"--verbose\"?\n> \n> I am not sure consistency with whom we are aiming for anymore with\n> that mixed to the proposal X-<.\n\nI think I put this in a wrong way. I don't advocate for curls UI and\ndon't think we should mimic it here. It's just a thing to consider if we\never find ourselves in this situation. Using the lowercase \"-v\" for\n\"version\" as proposed by this patch makes the most sense IMO. If we ever\nneed a shorthand for \"verbose\", \"-V\" could be the way to go.\n\n> (Side note) A tip for reviewers. Be suspicious of any change\n> that adds new things _in front_ of existing sequence. Question\n> if there is a good justification for it. If there isn't, see if\n> it makes it better if you instead append the new stuff to\n> existing sequence. If neither results in satisfying code,\n> perhaps it is good time to totally rewrite it to make both\n> existing and new stuff fit in the flow.\n\nThis is great advice, not just for reviewers. Thanks for taking the time\nto write this.\n\n> We may want to be a bit more explicit and readable, by spelling out\n> the expectation, i.e.\n> \n> \t\tif (!strcmp(\"--version\", argv[0]) || !strcmp(\"-v\", argv[0]))\n> \t\t\targv[0] = \"version\";\n> \t\telse if (!strcmp(\"--help\", argv[0]) || !strcmp(\"-h\", argv[0]))\n> \t\t\targv[0] = \"help\";\n> \n> This makes it clear that these two pseudo-commands, spelled with a\n> dash in front and stand for other commands, are the only thing we\n> care about and what their accepted spelling are.\n\nNice and precise. I incorporated this into v3.\n\n Documentation/git.txt | 4 +++-\n git.c | 11 +++++++----\n t/t0012-help.sh | 2 +-\n 3 files changed, 11 insertions(+), 6 deletions(-)\n\ndiff --git a/Documentation/git.txt b/Documentation/git.txt\nindex 13f83a2a3a..302607a496 100644\n--- a/Documentation/git.txt\n+++ b/Documentation/git.txt\n@@ -9,7 +9,7 @@ git - the stupid content tracker\n SYNOPSIS\n --------\n [verse]\n-'git' [--version] [--help] [-C ] [-c =]\n+'git' [-v | --version] [-h | --help] [-C ] [-c =]\n [--exec-path[=]] [--html-path] [--man-path] [--info-path]\n [-p|--paginate|-P|--no-pager] [--no-replace-objects] [--bare]\n [--git-dir=] [--work-tree=] [--namespace=]\n@@ -39,6 +39,7 @@ or https://git-scm.com/docs.\n \n OPTIONS\n -------\n+-v::\n --version::\n \tPrints the Git suite version that the 'git' program came from.\n +\n@@ -46,6 +47,7 @@ This option is internally converted to `git version ...` and accepts\n the same options as the linkgit:git-version[1] command. If `--help` is\n also given, it takes precedence over `--version`.\n \n+-h::\n --help::\n \tPrints the synopsis and a list of the most commonly used\n \tcommands. If the option `--all` or `-a` is given then all\ndiff --git a/git.c b/git.c\nindex a25940d72e..e2aeb57a35 100644\n--- a/git.c\n+++ b/git.c\n@@ -25,7 +25,7 @@ struct cmd_struct {\n };\n \n const char git_usage_string[] =\n-\tN_(\"git [--version] [--help] [-C ] [-c =]\\n\"\n+\tN_(\"git [-v | --version] [-h | --help] [-C ] [-c =]\\n\"\n \t \" [--exec-path[=]] [--html-path] [--man-path] [--info-path]\\n\"\n \t \" [-p | --paginate | -P | --no-pager] [--no-replace-objects] [--bare]\\n\"\n \t \" [--git-dir=] [--work-tree=] [--namespace=]\\n\"\n@@ -146,7 +146,8 @@ static int handle_options(const char ***argv, int *argc, int *envchanged)\n \t\t * commands can be written with \"--\" prepended\n \t\t * to make them look like flags.\n \t\t */\n-\t\tif (!strcmp(cmd, \"--help\") || !strcmp(cmd, \"--version\"))\n+\t\tif (!strcmp(cmd, \"--help\") || !strcmp(cmd, \"--version\") ||\n+\t\t !strcmp(cmd, \"-h\") || !strcmp(cmd, \"-v\"))\n \t\t\tbreak;\n \n \t\t/*\n@@ -892,8 +893,10 @@ int cmd_main(int argc, const char **argv)\n \targc--;\n \thandle_options(&argv, &argc, NULL);\n \tif (argc > 0) {\n-\t\t/* translate --help and --version into commands */\n-\t\tskip_prefix(argv[0], \"--\", &argv[0]);\n+\t\tif (!strcmp(\"--version\", argv[0]) || !strcmp(\"-v\", argv[0]))\n+\t\t\targv[0] = \"version\";\n+\t\telse if (!strcmp(\"--help\", argv[0]) || !strcmp(\"-h\", argv[0]))\n+\t\t\targv[0] = \"help\"; \n \t} else {\n \t\t/* The user didn't specify a command; give them help */\n \t\tcommit_pager_choice();\ndiff --git a/t/t0012-help.sh b/t/t0012-help.sh\nindex 6c3e1f7159..6c33a43690 100755\n--- a/t/t0012-help.sh\n+++ b/t/t0012-help.sh\n@@ -181,7 +181,7 @@ for cmd in git \"git help\"\n do\n \ttest_expect_success \"'$cmd' section spacing\" '\n \t\ttest_section_spacing_trailer git help <<-\\EOF &&\n-\t\tusage: git [--version] [--help] [-C ] [-c =]\n+\t\tusage: git [-v | --version] [-h | --help] [-C ] [-c =]\n \n \t\tThese are common Git commands used in various situations:\n \n-- \n2.35.1\n\n"},{"id":"452856","messageId":"220401.86y20pnofb.gmgdl@evledraar.gmail.com","threadId":"57638","inReplyTo":"xmqqsfqx28dv.fsf@gitster.g","subject":"Re: [PATCH v2] cli: add -v and -h shorthands","fromName":"Ævar Arnfjörð Bjarmason","fromEmail":"avarab@gmail.com","sentAt":"2022-04-01T09:23:39Z","receivedAt":"2022-04-01T09:27:58Z","isPatch":true,"sender":{"key":"avarab@gmail.com","avatar":"https://avatars.githubusercontent.com/u/45301?v=4"},"body":"\nOn Thu, Mar 31 2022, Junio C Hamano wrote:\n\n> Garrit Franke writes:\n>\n>> On 31.03.22 02:07, Ævar Arnfjörð Bjarmason wrote:\n>>\n>>> I think this is a good trade-off in this case. I.e. -v and -h are\n>>> commonly understood.\n>>\n>> An interesting observation I just made is that curl [0] uses both\n>> \"--verbose\" and \"--version\" on the top level [1][2] including\n>> shorthands. \"-v\" corresponds to \"verbose\", \"-V\" corresponds to\n>> \"version.\n>>\n>> Not that I'm a fan of this clutter, but it's a possible path to go\n>> down if we actually needed a second shorthand using this letter.\n>\n> Do you mean you want to use \"-V\" for version, instead of the \"-v\"\n> used in the patch, so that \"-v\" can be left for \"--verbose\"?\n>\n> I am not sure consistency with whom we are aiming for anymore with\n> that mixed to the proposal X-<.\n\nMaybe you've been convinced to accept -v and -h (I don't care much\neither way, honestly), but if not I wonder if this alternate approach\nwould make everyone in this thread happy (or at least mostly so):\n\ndiff --git a/git.c b/git.c\nindex a25940d72e8..929faa12537 100644\n--- a/git.c\n+++ b/git.c\n@@ -323,7 +323,12 @@ static int handle_options(const char ***argv, int *argc, int *envchanged)\n \t\t\t\texit(list_cmds(cmd));\n \t\t\t}\n \t\t} else {\n-\t\t\tfprintf(stderr, _(\"unknown option: %s\\n\"), cmd);\n+\t\t\tif (!strcmp(cmd, \"-h\"))\n+\t\t\t\tfprintf(stderr, _(\"unknown option: %s, did you mean --help?\\n\"), cmd);\n+\t\t\telse if (!strcmp(cmd, \"-v\"))\n+\t\t\t\tfprintf(stderr, _(\"unknown option: %s, did you mean --version?\\n\"), cmd);\n+\t\t\telse\n+\t\t\t\tfprintf(stderr, _(\"unknown option: %s\\n\"), cmd);\n \t\t\tusage(git_usage_string);\n \t\t}\n\n(Better to pass those as a parameter to the translation, but it's just a\nthrowaway demo patch for discussion)\n\nI.e. we could help the user in these cases by suggesting that they may\nhave meant --help or --version, while still leaving the door open to\nusing these short options for something else.\n\nIn git.c we don't use parse-options.c, but that might be a useful\naddition for it in general. I.e. to allow an option to define a list of\nknown alternative (but not understood!) aliases for itself.\n\nSo for the cases where we're about to emit an error about -v or whatever\nanyway, we could be a bit more helpful and suggest --version, even if we\ndidn't want to define that as a short option for whatever reason.\n"},{"id":"452903","messageId":"xmqqtubcyeow.fsf@gitster.g","threadId":"57638","inReplyTo":"220401.86y20pnofb.gmgdl@evledraar.gmail.com","subject":"Re: [PATCH v2] cli: add -v and -h shorthands","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2022-04-01T16:02:39Z","receivedAt":"2022-04-01T16:28:29Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Ævar Arnfjörð Bjarmason writes:\n\n>> Do you mean you want to use \"-V\" for version, instead of the \"-v\"\n>> used in the patch, so that \"-v\" can be left for \"--verbose\"?\n>>\n>> I am not sure consistency with whom we are aiming for anymore with\n>> that mixed to the proposal X-<.\n>\n> Maybe you've been convinced to accept -v and -h (I don't care much\n> either way, honestly), but if not I wonder if this alternate approach\n> would make everyone in this thread happy (or at least mostly so):\n\nI don't care too much about being similar to stuff made by other\npeople, compared to how much I care about internal consistency ;-)\n\nI do not think one extra level of \"unknown option\", even with hint,\nis worth the trouble. If we want to cater to those who expect \"-h\"\nto be more special than random \"-\", we should go\nall the way and make \"-h\" truly supported. If we do not, they can\nread \"git help git\" just like those who wonder what \"git -X\" means.\n\n"},{"id":"453026","messageId":"f39ae520-a370-a1c5-7dcc-1b7bba4306bf@slashdev.space","threadId":"57638","inReplyTo":"xmqqtubcyeow.fsf@gitster.g","subject":"Re: [PATCH v2] cli: add -v and -h shorthands","fromName":"Garrit Franke","fromEmail":"garrit@slashdev.space","sentAt":"2022-04-04T07:18:17Z","receivedAt":"2022-04-04T07:18:41Z","isPatch":true,"sender":{"key":"garrit@slashdev.space","avatar":"https://avatars.githubusercontent.com/u/32395585?v=4"},"body":"On 01.04.22 18:02, Junio C Hamano wrote:\n\n> I do not think one extra level of \"unknown option\", even with hint,\n> is worth the trouble. If we want to cater to those who expect \"-h\"\n> to be more special than random \"-\", we should go\n> all the way and make \"-h\" truly supported. If we do not, they can\n> read \"git help git\" just like those who wonder what \"git -X\" means.\n\n From what I gathered, we all agree that adding the \"-h\" shorthand is a \ngood addition to the UI. Given that the \"-v\" option is understandably \ncontroversial, I could cut it from this patch.\n\nThoughts?\n\n"},{"id":"453054","messageId":"xmqqbkxgstw8.fsf@gitster.g","threadId":"57638","inReplyTo":"f39ae520-a370-a1c5-7dcc-1b7bba4306bf@slashdev.space","subject":"Re: [PATCH v2] cli: add -v and -h shorthands","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2022-04-04T16:19:51Z","receivedAt":"2022-04-04T21:23:46Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Garrit Franke writes:\n\n> On 01.04.22 18:02, Junio C Hamano wrote:\n>\n>> I do not think one extra level of \"unknown option\", even with hint,\n>> is worth the trouble. If we want to cater to those who expect \"-h\"\n>> to be more special than random \"-\", we should go\n>> all the way and make \"-h\" truly supported. If we do not, they can\n>> read \"git help git\" just like those who wonder what \"git -X\" means.\n>\n> From what I gathered, we all agree that adding the \"-h\" shorthand is a\n> good addition to the UI. Given that the \"-v\" option is understandably \n> controversial, I could cut it from this patch.\n>\n> Thoughts?\n\nI do not care too deeply, and it is the most time efficient to just\ntake the last patch as-is. Nobody would care they used \"git -h\" or\n\"git -v\" only once and learned to use \"git help\" and \"git version\"\nanyway ;-)\n\n"}]}