{"thread":{"id":"45861","subject":"[PATCH 1/4] usability: don't ask questions if no reply is required","startedAt":"2017-05-03T16:30:14Z","lastAt":"2017-05-15T02:18:50Z","messageCount":41,"participants":["Jean-Noel Avila","Jonathan Nieder","Stefan Beller","Jean-Noël AVILA","Kerry, Richard","Ævar Arnfjörð Bjarmason","Junio C Hamano","Konstantin Khomoutov","Johannes Sixt"],"isPatch":true,"patchVersion":1,"patchTotal":4},"messages":[{"id":"318664","messageId":"20170503162931.30721-1-jn.avila@free.fr","threadId":"45861","inReplyTo":null,"subject":"[PATCH 1/4] usability: don't ask questions if no reply is required","fromName":"Jean-Noel Avila","fromEmail":"jn.avila@free.fr","sentAt":"2017-05-03T16:29:28Z","receivedAt":"2017-05-03T16:30:14Z","isPatch":true,"sender":{"key":"jn.avila@free.fr","avatar":"https://avatars.githubusercontent.com/u/156172?v=4"},"body":"As described in the bug report at\n\nhttps://github.com/git/git-scm.com/issues/999\n\nthe user was disconcerted by the question asked by the program not\nrequiring a reply from the user. To improve the general usability of\nthe Git suite, The following rule was applied:\n\nif the sentence\n * appears in a non-interactive session\n * is printed last before exit\n * is a question addressing the user (\"you\")\n\nthe sentence is turned into affirmative and proposes the option.\n\nSigned-off-by: Jean-Noel Avila \n---\n help.c | 4 ++--\n 1 file changed, 2 insertions(+), 2 deletions(-)\n\ndiff --git a/help.c b/help.c\nindex bc6cd19cf..4658a55c6 100644\n--- a/help.c\n+++ b/help.c\n@@ -411,8 +411,8 @@ const char *help_unknown_cmd(const char *cmd)\n \n \tif (SIMILAR_ENOUGH(best_similarity)) {\n \t\tfprintf_ln(stderr,\n-\t\t\t Q_(\"\\nDid you mean this?\",\n-\t\t\t \"\\nDid you mean one of these?\",\n+\t\t\t Q_(\"\\nThe most approaching command is\",\n+\t\t\t \"\\nThe most approaching commands are\",\n \t\t\t n));\n \n \t\tfor (i = 0; i < n; i++)\n-- \n2.12.0\n\n"},{"id":"318665","messageId":"20170503162931.30721-2-jn.avila@free.fr","threadId":"45861","inReplyTo":"20170503162931.30721-1-jn.avila@free.fr","subject":"[PATCH 2/4] usability: fix am and checkout for nevermind questions","fromName":"Jean-Noel Avila","fromEmail":"jn.avila@free.fr","sentAt":"2017-05-03T16:29:29Z","receivedAt":"2017-05-03T16:30:21Z","isPatch":true,"sender":{"key":"jn.avila@free.fr","avatar":"https://avatars.githubusercontent.com/u/156172?v=4"},"body":"Signed-off-by: Jean-Noel Avila \n---\n builtin/am.c | 4 ++--\n builtin/checkout.c | 2 +-\n 2 files changed, 3 insertions(+), 3 deletions(-)\n\ndiff --git a/builtin/am.c b/builtin/am.c\nindex a95dd8b4e..f5afa438d 100644\n--- a/builtin/am.c\n+++ b/builtin/am.c\n@@ -1312,7 +1312,7 @@ static int parse_mail(struct am_state *state, const char *mail)\n \t}\n \n \tif (is_empty_file(am_path(state, \"patch\"))) {\n-\t\tprintf_ln(_(\"Patch is empty. Was it split wrong?\"));\n+\t\tprintf_ln(_(\"Patch is empty. It may have been split wrong.\"));\n \t\tdie_user_resolve(state);\n \t}\n \n@@ -1940,7 +1940,7 @@ static void am_resolve(struct am_state *state)\n \n \tif (unmerged_cache()) {\n \t\tprintf_ln(_(\"You still have unmerged paths in your index.\\n\"\n-\t\t\t\"Did you forget to use 'git add'?\"));\n+\t\t\t\"You might want to use 'git add' on them.\"));\n \t\tdie_user_resolve(state);\n \t}\n \ndiff --git a/builtin/checkout.c b/builtin/checkout.c\nindex bfa5419f3..05037b9b6 100644\n--- a/builtin/checkout.c\n+++ b/builtin/checkout.c\n@@ -1287,7 +1287,7 @@ int cmd_checkout(int argc, const char **argv, const char *prefix)\n \t\t */\n \t\tif (opts.new_branch && argc == 1)\n \t\t\tdie(_(\"Cannot update paths and switch to branch '%s' at the same time.\\n\"\n-\t\t\t \"Did you intend to checkout '%s' which can not be resolved as commit?\"),\n+\t\t\t \"'%s' can not be resolved as commit, but it should.\"),\n \t\t\t opts.new_branch, argv[0]);\n \n \t\tif (opts.force_detach)\n-- \n2.12.0\n\n"},{"id":"318666","messageId":"20170503162931.30721-3-jn.avila@free.fr","threadId":"45861","inReplyTo":"20170503162931.30721-1-jn.avila@free.fr","subject":"[PATCH 3/4] read-tree.c: rework UI when merging no trees","fromName":"Jean-Noel Avila","fromEmail":"jn.avila@free.fr","sentAt":"2017-05-03T16:29:30Z","receivedAt":"2017-05-03T16:30:24Z","isPatch":true,"sender":{"key":"jn.avila@free.fr","avatar":"https://avatars.githubusercontent.com/u/156172?v=4"},"body":"The initial test was inherited from a previous commit, but it is no\nlonger needed, given the following switch case. Moreover, the question\nsentence ending the program has been replace by an assertative one.\n\nSigned-off-by: Jean-Noel Avila \n---\n builtin/read-tree.c | 5 +++--\n 1 file changed, 3 insertions(+), 2 deletions(-)\n\ndiff --git a/builtin/read-tree.c b/builtin/read-tree.c\nindex 23e212ee8..05296997c 100644\n--- a/builtin/read-tree.c\n+++ b/builtin/read-tree.c\n@@ -226,9 +226,10 @@ int cmd_read_tree(int argc, const char **argv, const char *unused_prefix)\n \t\tsetup_work_tree();\n \n \tif (opts.merge) {\n-\t\tif (stage < 2)\n-\t\t\tdie(\"just how do you expect me to merge %d trees?\", stage-1);\n \t\tswitch (stage - 1) {\n+\t\tcase 0:\n+\t\t\tdie(\"there are no trees to merge!\");\n+\t\t\tbreak;\n \t\tcase 1:\n \t\t\topts.fn = opts.prefix ? bind_merge : oneway_merge;\n \t\t\tbreak;\n-- \n2.12.0\n\n"},{"id":"318667","messageId":"20170503162931.30721-4-jn.avila@free.fr","threadId":"45861","inReplyTo":"20170503162931.30721-1-jn.avila@free.fr","subject":"[PATCH 4/4] git-filter-branch: be assertative on dying message","fromName":"Jean-Noel Avila","fromEmail":"jn.avila@free.fr","sentAt":"2017-05-03T16:29:31Z","receivedAt":"2017-05-03T16:30:40Z","isPatch":true,"sender":{"key":"jn.avila@free.fr","avatar":"https://avatars.githubusercontent.com/u/156172?v=4"},"body":"Signed-off-by: Jean-Noel Avila \n---\n git-filter-branch.sh | 2 +-\n 1 file changed, 1 insertion(+), 1 deletion(-)\n\ndiff --git a/git-filter-branch.sh b/git-filter-branch.sh\nindex 2b8cdba15..dd3a605d0 100755\n--- a/git-filter-branch.sh\n+++ b/git-filter-branch.sh\n@@ -239,7 +239,7 @@ git rev-parse --no-flags --revs-only --symbolic-full-name \\\n sed -e '/^^/d' \"$tempdir\"/raw-heads >\"$tempdir\"/heads\n \n test -s \"$tempdir\"/heads ||\n-\tdie \"Which ref do you want to rewrite?\"\n+\tdie \"You must specify a ref to rewrite\"\n \n GIT_INDEX_FILE=\"$(pwd)/../index\"\n export GIT_INDEX_FILE\n-- \n2.12.0\n\n"},{"id":"318672","messageId":"20170503164744.GY28740@aiede.svl.corp.google.com","threadId":"45861","inReplyTo":"20170503162931.30721-1-jn.avila@free.fr","subject":"Re: [PATCH 1/4] usability: don't ask questions if no reply is required","fromName":"Jonathan Nieder","fromEmail":"jrnieder@gmail.com","sentAt":"2017-05-03T16:47:44Z","receivedAt":"2017-05-03T16:47:52Z","isPatch":true,"sender":{"key":"jrnieder@gmail.com","avatar":"https://avatars.githubusercontent.com/u/281595?v=4"},"body":"Hi,\n\nJean-Noel Avila wrote:\n\n> As described in the bug report at\n>\n> https://github.com/git/git-scm.com/issues/999\n\nExternal issue tracker URLs have been known to change or disappear and\nwe try to make commit messages self-contained instead of relying on\nthem. It is common to put a 'Requested-by:' footer or sentence saying\n'Requested at by ' near the bottom of a commit message\nfor attribution and context. Relying on the bug report more heavily\nlike this example (instead of including any relevant information)\nmakes it harder for a reader to understand the patch easily in\none place.\n\nIn other words, instead of asking the reader to read the bug report,\nplease include pertinent information the reader needs to\nunderstand the patch here so they don't have to.\n\n> the user was disconcerted by the question asked by the program not\n> requiring a reply from the user. To improve the general usability of\n> the Git suite, The following rule was applied:\n>\n> if the sentence\n> * appears in a non-interactive session\n> * is printed last before exit\n> * is a question addressing the user (\"you\")\n>\n> the sentence is turned into affirmative and proposes the option.\n>\n> Signed-off-by: Jean-Noel Avila \n> ---\n> help.c | 4 ++--\n> 1 file changed, 2 insertions(+), 2 deletions(-)\n> \n> diff --git a/help.c b/help.c\n> index bc6cd19cf..4658a55c6 100644\n> --- a/help.c\n> +++ b/help.c\n> @@ -411,8 +411,8 @@ const char *help_unknown_cmd(const char *cmd)\n> \n> \tif (SIMILAR_ENOUGH(best_similarity)) {\n> \t\tfprintf_ln(stderr,\n> -\t\t\t Q_(\"\\nDid you mean this?\",\n> -\t\t\t \"\\nDid you mean one of these?\",\n> +\t\t\t Q_(\"\\nThe most approaching command is\",\n> +\t\t\t \"\\nThe most approaching commands are\",\n> \t\t\t n));\n\nFor what it's worth, I find the new text harder to understand than the\nold text.\n\nFrom the bug report:\n\n\tNow git says git: 'stahs' is not a git command. See 'git --help'.\n\tDid you mean this?\n\n\tstash\n\n\tGit asked if i meant git stash. and i entered yes. and git\n\tprinted the character y infinite times.\n\nIf I'm reading that correctly, the problem is not that questions are\nalarming but that Git did not cope well with the answer. When I try\nto reproduce it, I get\n\n\t$ git stahs\n\tWARNING: You called a Git command named 'stahs', which does not exist.\n\tContinuing under the assumption that you meant 'stash'\n\tin 5.0 seconds automatically...\n\nwhich is much clearer. After commenting out \"[help] autocorrect = 50\" in my\n~/.config/git/config, I get\n\n\t$ git stahs\n\tgit: 'stahs' is not a git command. See 'git --help'.\n\n\tDid you mean this?\n\t\tstash\n\nwhich does seem improvable, at least for consistency with the\nautocorrect case. For example, would something like\n\n\t$ git stahs\n\tfatal: You called a Git command named 'stahs', which does not exist.\n\thint: Did you mean 'git stash'?\n\nwork better? And the autocorrect case could say something like\n\n\t$ git stahs\n\twarning: You called a Git command named 'stahs', which does not exist.\n\twarning: Continuing under the assumption that you meant 'stash'\n\twarning: in 5.0 seconds automatically...\n\nIs contact information for the bug reporter available so we can try out\ndifferent wordings and see what works for them?\n\nThanks and hope that helps,\nJonathan\n"},{"id":"318673","messageId":"20170503165158.GZ28740@aiede.svl.corp.google.com","threadId":"45861","inReplyTo":"20170503162931.30721-2-jn.avila@free.fr","subject":"Re: [PATCH 2/4] usability: fix am and checkout for nevermind questions","fromName":"Jonathan Nieder","fromEmail":"jrnieder@gmail.com","sentAt":"2017-05-03T16:51:58Z","receivedAt":"2017-05-03T16:52:06Z","isPatch":true,"sender":{"key":"jrnieder@gmail.com","avatar":"https://avatars.githubusercontent.com/u/281595?v=4"},"body":"Jean-Noel Avila wrote:\n\n> Subject: usability: fix am and checkout for nevermind questions\n>\n> Signed-off-by: Jean-Noel Avila \n\nThanks for working on improving Git's UX. I agree with the goal in\ngeneral (we should not gratuitously surprise users) but I think I\nlack context for appreciating this particular example.\n\nThis is a good place to describe the motivation behind the patch and\nwhat effective change it would have.\n\n[...]\n> +++ b/builtin/am.c\n[...]\n> \tif (is_empty_file(am_path(state, \"patch\"))) {\n> -\t\tprintf_ln(_(\"Patch is empty. Was it split wrong?\"));\n> +\t\tprintf_ln(_(\"Patch is empty. It may have been split wrong.\"));\n[...]\n> \tif (unmerged_cache()) {\n> \t\tprintf_ln(_(\"You still have unmerged paths in your index.\\n\"\n> -\t\t\t\"Did you forget to use 'git add'?\"));\n> +\t\t\t\"You might want to use 'git add' on them.\"));\n[...]\n> \t\tif (opts.new_branch && argc == 1)\n> \t\t\tdie(_(\"Cannot update paths and switch to branch '%s' at the same time.\\n\"\n> -\t\t\t \"Did you intend to checkout '%s' which can not be resolved as commit?\"),\n> +\t\t\t \"'%s' can not be resolved as commit, but it should.\"),\n\nIn the current state I think this patch makes things worse (questions\nare not automatically a bad thing), which would make it especially\nuseful to see more about the motivation so we can find out whether\nthere's another way.\n\nThanks,\nJonathan\n"},{"id":"318674","messageId":"CAGZ79kb0CaoTpZ+HJEDygzuJ14dEDqaCyNcdHEN9_nnkaMhnzg@mail.gmail.com","threadId":"45861","inReplyTo":"20170503164744.GY28740@aiede.svl.corp.google.com","subject":"Re: [PATCH 1/4] usability: don't ask questions if no reply is required","fromName":"Stefan Beller","fromEmail":"sbeller@google.com","sentAt":"2017-05-03T16:58:56Z","receivedAt":"2017-05-03T16:59:03Z","isPatch":true,"sender":{"key":"stefanbeller@gmail.com","avatar":"https://avatars.githubusercontent.com/u/455868?v=4"},"body":"+cc rashmipai36@gmail.com\n\nOn Wed, May 3, 2017 at 9:47 AM, Jonathan Nieder wrote:\n> Hi,\n>\n> Jean-Noel Avila wrote:\n>\n>> As described in the bug report at\n>>\n>> https://github.com/git/git-scm.com/issues/999\n>\n> External issue tracker URLs have been known to change or disappear and\n> we try to make commit messages self-contained instead of relying on\n> them. It is common to put a 'Requested-by:' footer or sentence saying\n> 'Requested at by ' near the bottom of a commit message\n> for attribution and context. Relying on the bug report more heavily\n> like this example (instead of including any relevant information)\n> makes it harder for a reader to understand the patch easily in\n> one place.\n>\n> In other words, instead of asking the reader to read the bug report,\n> please include pertinent information the reader needs to\n> understand the patch here so they don't have to.\n>\n>> the user was disconcerted by the question asked by the program not\n>> requiring a reply from the user. To improve the general usability of\n>> the Git suite, The following rule was applied:\n>>\n>> if the sentence\n>> * appears in a non-interactive session\n>> * is printed last before exit\n>> * is a question addressing the user (\"you\")\n>>\n>> the sentence is turned into affirmative and proposes the option.\n>>\n>> Signed-off-by: Jean-Noel Avila \n>> ---\n>> help.c | 4 ++--\n>> 1 file changed, 2 insertions(+), 2 deletions(-)\n>>\n>> diff --git a/help.c b/help.c\n>> index bc6cd19cf..4658a55c6 100644\n>> --- a/help.c\n>> +++ b/help.c\n>> @@ -411,8 +411,8 @@ const char *help_unknown_cmd(const char *cmd)\n>>\n>> if (SIMILAR_ENOUGH(best_similarity)) {\n>> fprintf_ln(stderr,\n>> - Q_(\"\\nDid you mean this?\",\n>> - \"\\nDid you mean one of these?\",\n>> + Q_(\"\\nThe most approaching command is\",\n>> + \"\\nThe most approaching commands are\",\n>> n));\n>\n> For what it's worth, I find the new text harder to understand than the\n> old text.\n>\n> From the bug report:\n>\n> Now git says git: 'stahs' is not a git command. See 'git --help'.\n> Did you mean this?\n>\n> stash\n>\n> Git asked if i meant git stash. and i entered yes. and git\n> printed the character y infinite times.\n>\n> If I'm reading that correctly, the problem is not that questions are\n> alarming but that Git did not cope well with the answer. When I try\n> to reproduce it, I get\n>\n> $ git stahs\n> WARNING: You called a Git command named 'stahs', which does not exist.\n> Continuing under the assumption that you meant 'stash'\n> in 5.0 seconds automatically...\n>\n> which is much clearer. After commenting out \"[help] autocorrect = 50\" in my\n> ~/.config/git/config, I get\n>\n> $ git stahs\n> git: 'stahs' is not a git command. See 'git --help'.\n>\n> Did you mean this?\n> stash\n>\n> which does seem improvable, at least for consistency with the\n> autocorrect case. For example, would something like\n>\n> $ git stahs\n> fatal: You called a Git command named 'stahs', which does not exist.\n> hint: Did you mean 'git stash'?\n>\n> work better? And the autocorrect case could say something like\n>\n> $ git stahs\n> warning: You called a Git command named 'stahs', which does not exist.\n> warning: Continuing under the assumption that you meant 'stash'\n> warning: in 5.0 seconds automatically...\n>\n> Is contact information for the bug reporter available so we can try out\n> different wordings and see what works for them?\n\nyes, cc'd.\nAlso see\nhttps://public-inbox.org/git/CAOqCAXSOZCG8mijV+yATtmC1PFGYiOSqtraSdbhbP2rRHBO_Qg@mail.gmail.com\n\n>\n> Thanks and hope that helps,\n> Jonathan\n"},{"id":"318676","messageId":"20170503170401.GA28740@aiede.svl.corp.google.com","threadId":"45861","inReplyTo":"20170503162931.30721-3-jn.avila@free.fr","subject":"Re: [PATCH 3/4] read-tree.c: rework UI when merging no trees","fromName":"Jonathan Nieder","fromEmail":"jrnieder@gmail.com","sentAt":"2017-05-03T17:04:01Z","receivedAt":"2017-05-03T17:04:08Z","isPatch":true,"sender":{"key":"jrnieder@gmail.com","avatar":"https://avatars.githubusercontent.com/u/281595?v=4"},"body":"Hi,\n\nJean-Noel Avila wrote:\n\n> Subject: read-tree.c: rework UI when merging no trees\n\nnit: this is about user-facing behavior, not an implementation detail,\nso the part before the colon can be the command that changed\n(read-tree:).\n\nnit: the word \"rework\" is dangerous in a commit message in the same\nway as the word \"fix\" --- it stands for \"make better\", in a vague way\nthat leaves the reader guessing about how. Usually a more specific\ndescription can work better.\n\n> The initial test was inherited from a previous commit, but it is no\n> longer needed, given the following switch case. Moreover, the question\n> sentence ending the program has been replace by an assertative one.\n> \n> Signed-off-by: Jean-Noel Avila \n\nThis can have a simpler, short-and-sweet motivation:\n\n\tread-tree -m: make error message for merging 0 trees less smart-alecky\n\n\t\"git read-tree -m\" requires a tree argument to name the tree to be\n\tmerged in. Git uses a cutesy error message to say so and why:\n\n\t\t$ git read-tree -m\n\t\twarning: read-tree: emptying the index with no arguments is deprecated; use --empty\n\t\tfatal: just how do you expect me to merge 0 trees?\n\t\t$ git read-tree -m --empty\n\t\tfatal: just how do you expect me to merge 0 trees?\n\n\tWhen lucky, that could produce an ah-hah moment for the user, but it's\n\tmore likely to irritate and distract them.\n\n\tInstead, tell the user plainly that the tree argument is required. Also\n\tdocument this requirement in the git-read-tree(1) manpage where there is\n\troom to explain it in a more straightforward way.\n\nUnfortunately both 'git read-tree -h' and 'git read-tree --help' say nothing about\nthis. Ideas for wording there?\n\nThanks and hope that helps,\nJonathan\n"},{"id":"318677","messageId":"20170503170719.GB28740@aiede.svl.corp.google.com","threadId":"45861","inReplyTo":"20170503162931.30721-4-jn.avila@free.fr","subject":"Re: [PATCH 4/4] git-filter-branch: be assertative on dying message","fromName":"Jonathan Nieder","fromEmail":"jrnieder@gmail.com","sentAt":"2017-05-03T17:07:19Z","receivedAt":"2017-05-03T17:07:32Z","isPatch":true,"sender":{"key":"jrnieder@gmail.com","avatar":"https://avatars.githubusercontent.com/u/281595?v=4"},"body":"Hi,\n\nJean-Noel Avila wrote:\n\n> Signed-off-by: Jean-Noel Avila \n\nAs with the previous patches, this is a good place to put the motivation\nfor the patch.\n\n> ---\n> git-filter-branch.sh | 2 +-\n> 1 file changed, 1 insertion(+), 1 deletion(-)\n> \n> diff --git a/git-filter-branch.sh b/git-filter-branch.sh\n> index 2b8cdba15..dd3a605d0 100755\n> --- a/git-filter-branch.sh\n> +++ b/git-filter-branch.sh\n> @@ -239,7 +239,7 @@ git rev-parse --no-flags --revs-only --symbolic-full-name \\\n> sed -e '/^^/d' \"$tempdir\"/raw-heads >\"$tempdir\"/heads\n> \n> test -s \"$tempdir\"/heads ||\n> -\tdie \"Which ref do you want to rewrite?\"\n> +\tdie \"You must specify a ref to rewrite\"\n\nI find both the old and the new messages pretty uncompelling. The user\ngot the usage wrong but we don't know what they were trying to do ---\ne.g. maybe they specified the ref to rewrite but in the wrong place.\n\nWould e.g. a simple call to 'usage' work?\n\nThanks,\nJonathan\n"},{"id":"318680","messageId":"2484534.KmWiS2caPb@cayenne","threadId":"45861","inReplyTo":"20170503164744.GY28740@aiede.svl.corp.google.com","subject":"Re: [PATCH 1/4] usability: don't ask questions if no reply is required","fromName":"Jean-Noël AVILA","fromEmail":"jn.avila@free.fr","sentAt":"2017-05-03T17:37:38Z","receivedAt":"2017-05-03T17:38:01Z","isPatch":true,"sender":{"key":"jn.avila@free.fr","avatar":"https://avatars.githubusercontent.com/u/156172?v=4"},"body":"Le mercredi 3 mai 2017, 09:47:44 CEST Jonathan Nieder a écrit :\n> Hi,\n> \n> Jean-Noel Avila wrote:\n> > As described in the bug report at\n> > \n> > https://github.com/git/git-scm.com/issues/999\n> \n> External issue tracker URLs have been known to change or disappear and\n> we try to make commit messages self-contained instead of relying on\n> them. It is common to put a 'Requested-by:' footer or sentence saying\n> 'Requested at by ' near the bottom of a commit message\n> for attribution and context. Relying on the bug report more heavily\n> like this example (instead of including any relevant information)\n> makes it harder for a reader to understand the patch easily in\n> one place.\n> \n> In other words, instead of asking the reader to read the bug report,\n> please include pertinent information the reader needs to\n> understand the patch here so they don't have to.\n\nOk. Will include more context in the commit message and just provide the BT as \nan additional link.\n\n> \n> > the user was disconcerted by the question asked by the program not\n> > requiring a reply from the user. To improve the general usability of\n> > the Git suite, The following rule was applied:\n> > \n> > if the sentence\n> > \n> > * appears in a non-interactive session\n> > * is printed last before exit\n> > * is a question addressing the user (\"you\")\n> > \n> > the sentence is turned into affirmative and proposes the option.\n> > \n> > Signed-off-by: Jean-Noel Avila \n> > ---\n> > \n> > help.c | 4 ++--\n> > 1 file changed, 2 insertions(+), 2 deletions(-)\n> > \n> > diff --git a/help.c b/help.c\n> > index bc6cd19cf..4658a55c6 100644\n> > --- a/help.c\n> > +++ b/help.c\n> > @@ -411,8 +411,8 @@ const char *help_unknown_cmd(const char *cmd)\n> > \n> > \tif (SIMILAR_ENOUGH(best_similarity)) {\n> > \t\n> > \t\tfprintf_ln(stderr,\n> > \n> > -\t\t\t Q_(\"\\nDid you mean this?\",\n> > -\t\t\t \"\\nDid you mean one of these?\",\n> > +\t\t\t Q_(\"\\nThe most approaching command is\",\n> > +\t\t\t \"\\nThe most approaching commands are\",\n> > \n> > \t\t\t n));\n> \n> For what it's worth, I find the new text harder to understand than the\n> old text.\n> \n> From the bug report:\n> \n> \tNow git says git: 'stahs' is not a git command. See 'git --help'.\n> \tDid you mean this?\n> \n> \tstash\n> \n> \tGit asked if i meant git stash. and i entered yes. and git\n> \tprinted the character y infinite times.\n> \n> If I'm reading that correctly, the problem is not that questions are\n> alarming but that Git did not cope well with the answer. When I try\n> to reproduce it, I get\n\nNo, I don't think that the questions are alarming. The whole point is that Git \nno longer runs when the user enters its reply. In the case of the bug report, \nthe user was unlucky to type in the name of the shell command `yes` because he \nwas thinking that Git was still running interactively, due to the question at \nthe end of the run.\n\nSo this patch series'aim is simply to get rid of asking questions just before \nexiting. Even if a question might seem more user friendly, it's insufficiently \nformal to indicate to the user that there's no point replying. The question \nwas just a hint, and it should presented as such.\n\nTo be fair, I'm not accustomed enough to the code to know exactly in which \ncases the given strings are occurring (except here). All the patch series \ntries to tackle this at different levels. Maybe squashing them all would be \nbetter for understanding. \n\n> \n> \t$ git stahs\n> \tWARNING: You called a Git command named 'stahs', which does not exist.\n> \tContinuing under the assumption that you meant 'stash'\n> \tin 5.0 seconds automatically...\n> \n> which is much clearer. After commenting out \"[help] autocorrect = 50\" in my\n> ~/.config/git/config, I get\n> \n> \t$ git stahs\n> \tgit: 'stahs' is not a git command. See 'git --help'.\n> \n> \tDid you mean this?\n> \t\tstash\n> \n> which does seem improvable, at least for consistency with the\n> autocorrect case. For example, would something like\n> \n> \t$ git stahs\n> \tfatal: You called a Git command named 'stahs', which does not exist.\n> \thint: Did you mean 'git stash'?\n> \n> work better? And the autocorrect case could say something like\n\nWould adding a \"hint:\" prefix be enough to provide context? I don't think so. \nI'd prefer to be clearer on the objectives of the printed information, even at \nthe risk of being clumsy.\n\n\n>\n> \t$ git stahs\n> \twarning: You called a Git command named 'stahs', which does not exist.\n> \twarning: Continuing under the assumption that you meant 'stash'\n> \twarning: in 5.0 seconds automatically...\n> \n> Is contact information for the bug reporter available so we can try out\n> different wordings and see what works for them?\n\nI guess so. The discussion on github is still open and only depends on the \nwillingness of the reporter to reply.\n\n\n> \n> Thanks and hope that helps,\n> Jonathan\n\n\n"},{"id":"318688","messageId":"2001640.bFkheBfX4c@cayenne","threadId":"45861","inReplyTo":"20170503165158.GZ28740@aiede.svl.corp.google.com","subject":"Re: [PATCH 2/4] usability: fix am and checkout for nevermind questions","fromName":"Jean-Noël AVILA","fromEmail":"jn.avila@free.fr","sentAt":"2017-05-03T18:35:06Z","receivedAt":"2017-05-03T18:35:13Z","isPatch":true,"sender":{"key":"jn.avila@free.fr","avatar":"https://avatars.githubusercontent.com/u/156172?v=4"},"body":"Le mercredi 3 mai 2017 09:51:58 CEST, vous avez écrit :\n> Jean-Noel Avila wrote:\n> > Subject: usability: fix am and checkout for nevermind questions\n> > \n> > Signed-off-by: Jean-Noel Avila \n> \n> Thanks for working on improving Git's UX. I agree with the goal in\n> general (we should not gratuitously surprise users) but I think I\n> lack context for appreciating this particular example.\n> \n> This is a good place to describe the motivation behind the patch and\n> what effective change it would have.\n> \n> [...]\n> \n> > +++ b/builtin/am.c\n> \n> [...]\n> \n> > \tif (is_empty_file(am_path(state, \"patch\"))) {\n> > \n> > -\t\tprintf_ln(_(\"Patch is empty. Was it split wrong?\"));\n> > +\t\tprintf_ln(_(\"Patch is empty. It may have been split wrong.\"));\n> \n> [...]\n> \n> > \tif (unmerged_cache()) {\n> > \t\n> > \t\tprintf_ln(_(\"You still have unmerged paths in your index.\\n\"\n> > \n> > -\t\t\t\"Did you forget to use 'git add'?\"));\n> > +\t\t\t\"You might want to use 'git add' on them.\"));\n> \n> [...]\n> \n> > \t\tif (opts.new_branch && argc == 1)\n> > \t\t\n> > \t\t\tdie(_(\"Cannot update paths and switch to branch '%s' at the same\n> > \t\t\ttime.\\n\"\n> > \n> > -\t\t\t \"Did you intend to checkout '%s' which can not be resolved \nas\n> > commit?\"), +\t\t\t \"'%s' can not be resolved as commit, but it\n> > should.\"),\n> \n> In the current state I think this patch makes things worse (questions\n> are not automatically a bad thing), which would make it especially\n> useful to see more about the motivation so we can find out whether\n> there's another way.\n> \n\nI am not a UX designer, but for me, in the context of interaction with a \ncommand line program, any question that does not accept a reply is bad design. \nThat also means that any command that does not run interactively should not \nask questions. The shell interface is too informal to allow being loose on the \nprogram side. Comparatively to a GUI, where a label is formally informative \nand a popping-up dialog box asks for user input.\n\nThis patch should indeed be squashed with the first one. They are small changes \nin strings printed when dying. They would share the more extended commit \nmessage.\n\n\n\n"},{"id":"318689","messageId":"3080937.1HJCWGH9Pz@cayenne","threadId":"45861","inReplyTo":"20170503170401.GA28740@aiede.svl.corp.google.com","subject":"Re: [PATCH 3/4] read-tree.c: rework UI when merging no trees","fromName":"Jean-Noël AVILA","fromEmail":"jn.avila@free.fr","sentAt":"2017-05-03T18:39:50Z","receivedAt":"2017-05-03T18:39:57Z","isPatch":true,"sender":{"key":"jn.avila@free.fr","avatar":"https://avatars.githubusercontent.com/u/156172?v=4"},"body":"Le mercredi 3 mai 2017, 10:04:01 CEST Jonathan Nieder a écrit :\n> Hi,\n> \n> Jean-Noel Avila wrote:\n> > Subject: read-tree.c: rework UI when merging no trees\n> \n> nit: this is about user-facing behavior, not an implementation detail,\n> so the part before the colon can be the command that changed\n> (read-tree:).\n> \n> nit: the word \"rework\" is dangerous in a commit message in the same\n> way as the word \"fix\" --- it stands for \"make better\", in a vague way\n> that leaves the reader guessing about how. Usually a more specific\n> description can work better.\n> \n\nIn fact, this patch is two fold:\n\n * reword the question in the die() call. I realize now that when passed to \ndie(), the string is prepended with \"fatal:\". That's an hint that the question \ndoes not require a reply, but ruling out any doubt would be better.\n * rework the local logic which was inherited from history. This is \nfunctionally equivalent to the previous version, just cleaner.\n\n> > The initial test was inherited from a previous commit, but it is no\n> > longer needed, given the following switch case. Moreover, the question\n> > sentence ending the program has been replace by an assertative one.\n> > \n> > Signed-off-by: Jean-Noel Avila \n> \n> This can have a simpler, short-and-sweet motivation:\n> \n> \tread-tree -m: make error message for merging 0 trees less smart-alecky\n> \n> \t\"git read-tree -m\" requires a tree argument to name the tree to be\n> \tmerged in. Git uses a cutesy error message to say so and why:\n> \n> \t\t$ git read-tree -m\n> \t\twarning: read-tree: emptying the index with no arguments is deprecated;\n> use --empty fatal: just how do you expect me to merge 0 trees?\n> \t\t$ git read-tree -m --empty\n> \t\tfatal: just how do you expect me to merge 0 trees?\n> \n> \tWhen lucky, that could produce an ah-hah moment for the user, but it's\n> \tmore likely to irritate and distract them.\n> \n> \tInstead, tell the user plainly that the tree argument is required. Also\n> \tdocument this requirement in the git-read-tree(1) manpage where there is\n> \troom to explain it in a more straightforward way.\n> \n\nThank you very much for this message! May I s-o-b you?\n\nAs hinted, I'll add the documentation part. ;-)\n\n> Unfortunately both 'git read-tree -h' and 'git read-tree --help' say nothing\n> about this. Ideas for wording there?\n\nNext pach series will propose this.\n\n> \n> Thanks and hope that helps,\n> Jonathan\n\n\n"},{"id":"318701","messageId":"20170503210726.24121-1-jn.avila@free.fr","threadId":"45861","inReplyTo":"20170503162931.30721-1-jn.avila@free.fr","subject":"[PATCH v2 1/3] usability: don't ask questions if no reply is required","fromName":"Jean-Noel Avila","fromEmail":"jn.avila@free.fr","sentAt":"2017-05-03T21:07:24Z","receivedAt":"2017-05-03T21:07:49Z","isPatch":true,"sender":{"key":"jn.avila@free.fr","avatar":"https://avatars.githubusercontent.com/u/156172?v=4"},"body":"There has been a bug report by a corporate user that stated that\n\"spelling mistake of stash followed by a yes prints character 'y'\ninfinite times.\"\n\nThis analysis was false. When the spelling of a command contains\nerrors, the git program tries to help the user by providing candidates\nwhich are close to the unexisting command. E.g Git prints the\nfollowing:\n\n git: 'stahs' is not a git command. See 'git --help'.\n Did you mean this?\n\n stash\n\nand then exits.\n\nThe problem with this hint is that it is not formally indicated as an\nhint and the user is in fact encouraged to reply to the question,\nwhereas the Git command is already finished.\n\nThe user was unlucky enough that it was the command he was looking\nfor, and replied \"yes\" on the command line, effectively launching the\n`yes` program.\n\nThe initial error is that the Git programs, when launched in\ncommand-line mode (without interaction) must not ask questions,\nbecause these questions would normally require a user input as a reply\nwhile they won't handle indeed. That's a source of confusion on UX\nlevel.\n\nTo improve the general usability of the Git suite, the following rule\nwas applied:\n\nif the sentence\n * appears in a non-interactive session\n * is printed last before exit\n * is a question addressing the user (\"you\")\n\nthe sentence is turned into affirmative and proposes the option.\n\nThe basic rewording of the question sentences has been extended to\nother spots found in the source.\n\nRequested at https://github.com/git/git-scm.com/issues/999 by rpai1\n\nSigned-off-by: Jean-Noel Avila \n---\n builtin/am.c | 4 ++--\n builtin/checkout.c | 2 +-\n help.c | 4 ++--\n 3 files changed, 5 insertions(+), 5 deletions(-)\n\ndiff --git a/builtin/am.c b/builtin/am.c\nindex a95dd8b4e..f5afa438d 100644\n--- a/builtin/am.c\n+++ b/builtin/am.c\n@@ -1312,7 +1312,7 @@ static int parse_mail(struct am_state *state, const char *mail)\n \t}\n \n \tif (is_empty_file(am_path(state, \"patch\"))) {\n-\t\tprintf_ln(_(\"Patch is empty. Was it split wrong?\"));\n+\t\tprintf_ln(_(\"Patch is empty. It may have been split wrong.\"));\n \t\tdie_user_resolve(state);\n \t}\n \n@@ -1940,7 +1940,7 @@ static void am_resolve(struct am_state *state)\n \n \tif (unmerged_cache()) {\n \t\tprintf_ln(_(\"You still have unmerged paths in your index.\\n\"\n-\t\t\t\"Did you forget to use 'git add'?\"));\n+\t\t\t\"You might want to use 'git add' on them.\"));\n \t\tdie_user_resolve(state);\n \t}\n \ndiff --git a/builtin/checkout.c b/builtin/checkout.c\nindex bfa5419f3..05037b9b6 100644\n--- a/builtin/checkout.c\n+++ b/builtin/checkout.c\n@@ -1287,7 +1287,7 @@ int cmd_checkout(int argc, const char **argv, const char *prefix)\n \t\t */\n \t\tif (opts.new_branch && argc == 1)\n \t\t\tdie(_(\"Cannot update paths and switch to branch '%s' at the same time.\\n\"\n-\t\t\t \"Did you intend to checkout '%s' which can not be resolved as commit?\"),\n+\t\t\t \"'%s' can not be resolved as commit, but it should.\"),\n \t\t\t opts.new_branch, argv[0]);\n \n \t\tif (opts.force_detach)\ndiff --git a/help.c b/help.c\nindex bc6cd19cf..4658a55c6 100644\n--- a/help.c\n+++ b/help.c\n@@ -411,8 +411,8 @@ const char *help_unknown_cmd(const char *cmd)\n \n \tif (SIMILAR_ENOUGH(best_similarity)) {\n \t\tfprintf_ln(stderr,\n-\t\t\t Q_(\"\\nDid you mean this?\",\n-\t\t\t \"\\nDid you mean one of these?\",\n+\t\t\t Q_(\"\\nThe most approaching command is\",\n+\t\t\t \"\\nThe most approaching commands are\",\n \t\t\t n));\n \n \t\tfor (i = 0; i < n; i++)\n-- \n2.12.0\n\n"},{"id":"318702","messageId":"20170503210726.24121-2-jn.avila@free.fr","threadId":"45861","inReplyTo":"20170503210726.24121-1-jn.avila@free.fr","subject":"[PATCH v2 2/3] read-tree -m: make error message for merging 0 trees less smart aleck","fromName":"Jean-Noel Avila","fromEmail":"jn.avila@free.fr","sentAt":"2017-05-03T21:07:25Z","receivedAt":"2017-05-03T21:07:57Z","isPatch":true,"sender":{"key":"jn.avila@free.fr","avatar":"https://avatars.githubusercontent.com/u/156172?v=4"},"body":"\"git read-tree -m\" requires a tree argument to name the tree to be\nmerged in. Git uses a cutesy error message to say so and why:\n\n $ git read-tree -m\n warning: read-tree: emptying the index with no arguments is\n deprecated; use --empty\n fatal: just how do you expect me to merge 0 trees?\n $ git read-tree -m --empty\n fatal: just how do you expect me to merge 0 trees?\n\nWhen lucky, that could produce an ah-hah moment for the user, but it's\nmore likely to irritate and distract them.\n\nInstead, tell the user plainly that the tree argument is\nrequired. Also document this requirement in the git-read-tree(1)\nmanpage where there is room to explain it in a more straightforward way.\n\nSigned-off-by: Jean-Noel Avila \nSigned-off-by: Jonathan Nieder \n---\n Documentation/git-read-tree.txt | 8 ++++----\n builtin/read-tree.c | 7 ++++---\n 2 files changed, 8 insertions(+), 7 deletions(-)\n\ndiff --git a/Documentation/git-read-tree.txt b/Documentation/git-read-tree.txt\nindex ed9d63ef4..7cd9c6306 100644\n--- a/Documentation/git-read-tree.txt\n+++ b/Documentation/git-read-tree.txt\n@@ -135,10 +135,10 @@ OPTIONS\n \n Merging\n -------\n-If `-m` is specified, 'git read-tree' can perform 3 kinds of\n-merge, a single tree merge if only 1 tree is given, a\n-fast-forward merge with 2 trees, or a 3-way merge if 3 trees are\n-provided.\n+If `-m` is specified, at least one tree must be given on the command\n+line. 'git read-tree' can perform 3 kinds of merge, a single tree\n+merge if only 1 tree is given, a fast-forward merge with 2 trees, or a\n+3-way merge if 3 trees are provided.\n \n \n Single Tree Merge\ndiff --git a/builtin/read-tree.c b/builtin/read-tree.c\nindex 23e212ee8..68c5b0ca4 100644\n--- a/builtin/read-tree.c\n+++ b/builtin/read-tree.c\n@@ -132,7 +132,7 @@ int cmd_read_tree(int argc, const char **argv, const char *unused_prefix)\n \t\tOPT_BOOL(0, \"empty\", &read_empty,\n \t\t\t N_(\"only empty the index\")),\n \t\tOPT__VERBOSE(&opts.verbose_update, N_(\"be verbose\")),\n-\t\tOPT_GROUP(N_(\"Merging\")),\n+\t\tOPT_GROUP(N_(\"Merging (needs at least one tree-ish\")),\n \t\tOPT_BOOL('m', NULL, &opts.merge,\n \t\t\t N_(\"perform a merge in addition to a read\")),\n \t\tOPT_BOOL(0, \"trivial\", &opts.trivial_merges_only,\n@@ -226,9 +226,10 @@ int cmd_read_tree(int argc, const char **argv, const char *unused_prefix)\n \t\tsetup_work_tree();\n \n \tif (opts.merge) {\n-\t\tif (stage < 2)\n-\t\t\tdie(\"just how do you expect me to merge %d trees?\", stage-1);\n \t\tswitch (stage - 1) {\n+\t\tcase 0:\n+\t\t\tdie(\"you must specify at least one tree to merge\");\n+\t\t\tbreak;\n \t\tcase 1:\n \t\t\topts.fn = opts.prefix ? bind_merge : oneway_merge;\n \t\t\tbreak;\n-- \n2.12.0\n\n"},{"id":"318703","messageId":"20170503210726.24121-3-jn.avila@free.fr","threadId":"45861","inReplyTo":"20170503210726.24121-1-jn.avila@free.fr","subject":"[PATCH v2 3/3] git-filter-branch: make the error msg when missing branch more open","fromName":"Jean-Noel Avila","fromEmail":"jn.avila@free.fr","sentAt":"2017-05-03T21:07:26Z","receivedAt":"2017-05-03T21:07:58Z","isPatch":true,"sender":{"key":"jn.avila@free.fr","avatar":"https://avatars.githubusercontent.com/u/156172?v=4"},"body":"git-filter-branch requires the specification of a branch by one way or\nanother. If no branch appears to have been specified, we know the user\ngot the usage wrong but we don't know what they were trying to do ---\ne.g. maybe they specified the ref to rewrite but in the wrong place.\n\nThe safest solution is to just print the usage in this case.\n\nSigned-off-by: Jean-Noel Avila \n---\n git-filter-branch.sh | 2 +-\n 1 file changed, 1 insertion(+), 1 deletion(-)\n\ndiff --git a/git-filter-branch.sh b/git-filter-branch.sh\nindex 2b8cdba15..bda2bae23 100755\n--- a/git-filter-branch.sh\n+++ b/git-filter-branch.sh\n@@ -239,7 +239,7 @@ git rev-parse --no-flags --revs-only --symbolic-full-name \\\n sed -e '/^^/d' \"$tempdir\"/raw-heads >\"$tempdir\"/heads\n \n test -s \"$tempdir\"/heads ||\n-\tdie \"Which ref do you want to rewrite?\"\n+\tusage\n \n GIT_INDEX_FILE=\"$(pwd)/../index\"\n export GIT_INDEX_FILE\n-- \n2.12.0\n\n"},{"id":"318732","messageId":"61C67DC73308BD49B2D4B65072480DBA2BDA554E@DEERLM99EZ1MSX.ww931.my-it-solutions.net","threadId":"45861","inReplyTo":"20170503210726.24121-1-jn.avila@free.fr","subject":"RE: [PATCH v2 1/3] usability: don't ask questions if no reply is required","fromName":"Kerry, Richard","fromEmail":"richard.kerry@atos.net","sentAt":"2017-05-04T08:52:43Z","receivedAt":"2017-05-04T08:58:15Z","isPatch":true,"sender":{"key":"richard.kerry@atos.net","avatar":null},"body":"\nMay I suggest that \" The most approaching commands\" doesn't make much sense as English (I don't think a command can \"approach\").\nPerhaps it should be \" The most appropriate commands\".\n\n\nRegards,\nRichard.\n\n\n\n\n\nRichard Kerry\nBNCS Engineer, SI SOL Telco & Media Vertical Practice\n\nT: +44 (0)20 3618 2669\nM: +44 (0)7812 325518\nLync: +44 (0) 20 3618 0778\nRoom G300, Stadium House, Wood Lane, London, W12 7TA\nrichard.kerry@atos.net\n\n\n\n\n-----Original Message-----\nFrom: git-owner@vger.kernel.org [mailto:git-owner@vger.kernel.org] On Behalf Of Jean-Noel Avila\nSent: Wednesday, May 03, 2017 10:07 PM\nTo: git@vger.kernel.org\nCc: rashmipai36@gmail.com; Jean-Noel Avila \nSubject: [PATCH v2 1/3] usability: don't ask questions if no reply is required\n\nThere has been a bug report by a corporate user that stated that \"spelling mistake of stash followed by a yes prints character 'y'\ninfinite times.\"\n\nThis analysis was false. When the spelling of a command contains errors, the git program tries to help the user by providing candidates which are close to the unexisting command. E.g Git prints the\nfollowing:\n\n git: 'stahs' is not a git command. See 'git --help'.\n Did you mean this?\n\n stash\n\nand then exits.\n\nThe problem with this hint is that it is not formally indicated as an hint and the user is in fact encouraged to reply to the question, whereas the Git command is already finished.\n\nThe user was unlucky enough that it was the command he was looking for, and replied \"yes\" on the command line, effectively launching the `yes` program.\n\nThe initial error is that the Git programs, when launched in command-line mode (without interaction) must not ask questions, because these questions would normally require a user input as a reply while they won't handle indeed. That's a source of confusion on UX level.\n\nTo improve the general usability of the Git suite, the following rule was applied:\n\nif the sentence\n * appears in a non-interactive session\n * is printed last before exit\n * is a question addressing the user (\"you\")\n\nthe sentence is turned into affirmative and proposes the option.\n\nThe basic rewording of the question sentences has been extended to other spots found in the source.\n\nRequested at https://github.com/git/git-scm.com/issues/999 by rpai1\n\nSigned-off-by: Jean-Noel Avila \n---\n builtin/am.c | 4 ++--\n builtin/checkout.c | 2 +-\n help.c | 4 ++--\n 3 files changed, 5 insertions(+), 5 deletions(-)\n\ndiff --git a/builtin/am.c b/builtin/am.c index a95dd8b4e..f5afa438d 100644\n--- a/builtin/am.c\n+++ b/builtin/am.c\n@@ -1312,7 +1312,7 @@ static int parse_mail(struct am_state *state, const char *mail)\n }\n\n if (is_empty_file(am_path(state, \"patch\"))) {\n- printf_ln(_(\"Patch is empty. Was it split wrong?\"));\n+ printf_ln(_(\"Patch is empty. It may have been split wrong.\"));\n die_user_resolve(state);\n }\n\n@@ -1940,7 +1940,7 @@ static void am_resolve(struct am_state *state)\n\n if (unmerged_cache()) {\n printf_ln(_(\"You still have unmerged paths in your index.\\n\"\n- \"Did you forget to use 'git add'?\"));\n+ \"You might want to use 'git add' on them.\"));\n die_user_resolve(state);\n }\n\ndiff --git a/builtin/checkout.c b/builtin/checkout.c index bfa5419f3..05037b9b6 100644\n--- a/builtin/checkout.c\n+++ b/builtin/checkout.c\n@@ -1287,7 +1287,7 @@ int cmd_checkout(int argc, const char **argv, const char *prefix)\n */\n if (opts.new_branch && argc == 1)\n die(_(\"Cannot update paths and switch to branch '%s' at the same time.\\n\"\n- \"Did you intend to checkout '%s' which can not be resolved as commit?\"),\n+ \"'%s' can not be resolved as commit, but it should.\"),\n opts.new_branch, argv[0]);\n\n if (opts.force_detach)\ndiff --git a/help.c b/help.c\nindex bc6cd19cf..4658a55c6 100644\n--- a/help.c\n+++ b/help.c\n@@ -411,8 +411,8 @@ const char *help_unknown_cmd(const char *cmd)\n\n if (SIMILAR_ENOUGH(best_similarity)) {\n fprintf_ln(stderr,\n- Q_(\"\\nDid you mean this?\",\n- \"\\nDid you mean one of these?\",\n+ Q_(\"\\nThe most approaching command is\",\n+ \"\\nThe most approaching commands are\",\n n));\n\n for (i = 0; i < n; i++)\n--\n2.12.0\n\nAtos, Atos Consulting, Worldline and Canopy The Open Cloud Company are trading names used by the Atos group. The following trading entities are registered in England and Wales: Atos IT Services UK Limited (registered number 01245534), Atos Consulting Limited (registered number 04312380), Atos Worldline UK Limited (registered number 08514184) and Canopy The Open Cloud Company Limited (registration number 08011902). The registered office for each is at 4 Triton Square, Regent’s Place, London, NW1 3HG.The VAT No. for each is: GB232327983.\n\nThis e-mail and the documents attached are confidential and intended solely for the addressee, and may contain confidential or privileged information. If you receive this e-mail in error, you are not authorised to copy, disclose, use or retain it. Please notify the sender immediately and delete this email from your systems. As emails may be intercepted, amended or lost, they are not secure. Atos therefore can accept no liability for any errors or their content. Although Atos endeavours to maintain a virus-free network, we do not warrant that this transmission is virus-free and can accept no liability for any damages resulting from any virus transmitted. The risks are deemed to be accepted by everyone who communicates with Atos by email.\n"},{"id":"318733","messageId":"CACBZZX77Ad120bgTxJd+jqvPEX81BEYWrXnN2TeK+UgT63816w@mail.gmail.com","threadId":"45861","inReplyTo":"61C67DC73308BD49B2D4B65072480DBA2BDA554E@DEERLM99EZ1MSX.ww931.my-it-solutions.net","subject":"Re: [PATCH v2 1/3] usability: don't ask questions if no reply is required","fromName":"Ævar Arnfjörð Bjarmason","fromEmail":"avarab@gmail.com","sentAt":"2017-05-04T09:09:47Z","receivedAt":"2017-05-04T09:10:20Z","isPatch":true,"sender":{"key":"avarab@gmail.com","avatar":"https://avatars.githubusercontent.com/u/45301?v=4"},"body":"On Thu, May 4, 2017 at 10:52 AM, Kerry, Richard wrote:\n>\n> May I suggest that \" The most approaching commands\" doesn't make much sense as English (I don't think a command can \"approach\").\n> Perhaps it should be \" The most appropriate commands\".\n\nI had the same concern, saying \"appropriate\" is IMO also confusing.\nThe point of this UI is not to point out what you should be running,\nwhich \"appropriate\" implies, but just \"we couldn't find what you\nmeant, did you mean one of these?\".\n\nI think nothing needs to change here. The whole premise here is that a\nprogram should never ask a question when you can't give an answer, I\nthink that's nonsense. There's such a thing as a rhetorical question,\nand sometimes using that form is the most obvious & succinct way to\nput things.\n\nWhich is not to say that phrasing these things as a non-question can't\nbe better, but the suggestions so far just seem more complex.\n\nAlso keep in mind that a huge part of the user base for git using the\nEnglish UI consists of non-native speakers, and when in doubt we\nshould definitely be picking simpler English like \"did you mean?\" v.s.\nalternatives with >10 character more obscure words.\n\n> Richard Kerry\n> BNCS Engineer, SI SOL Telco & Media Vertical Practice\n>\n> T: +44 (0)20 3618 2669\n> M: +44 (0)7812 325518\n> Lync: +44 (0) 20 3618 0778\n> Room G300, Stadium House, Wood Lane, London, W12 7TA\n> richard.kerry@atos.net\n>\n>\n>\n>\n> -----Original Message-----\n> From: git-owner@vger.kernel.org [mailto:git-owner@vger.kernel.org] On Behalf Of Jean-Noel Avila\n> Sent: Wednesday, May 03, 2017 10:07 PM\n> To: git@vger.kernel.org\n> Cc: rashmipai36@gmail.com; Jean-Noel Avila \n> Subject: [PATCH v2 1/3] usability: don't ask questions if no reply is required\n>\n> There has been a bug report by a corporate user that stated that \"spelling mistake of stash followed by a yes prints character 'y'\n> infinite times.\"\n>\n> This analysis was false. When the spelling of a command contains errors, the git program tries to help the user by providing candidates which are close to the unexisting command. E.g Git prints the\n> following:\n>\n> git: 'stahs' is not a git command. See 'git --help'.\n> Did you mean this?\n>\n> stash\n>\n> and then exits.\n>\n> The problem with this hint is that it is not formally indicated as an hint and the user is in fact encouraged to reply to the question, whereas the Git command is already finished.\n>\n> The user was unlucky enough that it was the command he was looking for, and replied \"yes\" on the command line, effectively launching the `yes` program.\n>\n> The initial error is that the Git programs, when launched in command-line mode (without interaction) must not ask questions, because these questions would normally require a user input as a reply while they won't handle indeed. That's a source of confusion on UX level.\n>\n> To improve the general usability of the Git suite, the following rule was applied:\n>\n> if the sentence\n> * appears in a non-interactive session\n> * is printed last before exit\n> * is a question addressing the user (\"you\")\n>\n> the sentence is turned into affirmative and proposes the option.\n>\n> The basic rewording of the question sentences has been extended to other spots found in the source.\n>\n> Requested at https://github.com/git/git-scm.com/issues/999 by rpai1\n>\n> Signed-off-by: Jean-Noel Avila \n> ---\n> builtin/am.c | 4 ++--\n> builtin/checkout.c | 2 +-\n> help.c | 4 ++--\n> 3 files changed, 5 insertions(+), 5 deletions(-)\n>\n> diff --git a/builtin/am.c b/builtin/am.c index a95dd8b4e..f5afa438d 100644\n> --- a/builtin/am.c\n> +++ b/builtin/am.c\n> @@ -1312,7 +1312,7 @@ static int parse_mail(struct am_state *state, const char *mail)\n> }\n>\n> if (is_empty_file(am_path(state, \"patch\"))) {\n> - printf_ln(_(\"Patch is empty. Was it split wrong?\"));\n> + printf_ln(_(\"Patch is empty. It may have been split wrong.\"));\n> die_user_resolve(state);\n> }\n>\n> @@ -1940,7 +1940,7 @@ static void am_resolve(struct am_state *state)\n>\n> if (unmerged_cache()) {\n> printf_ln(_(\"You still have unmerged paths in your index.\\n\"\n> - \"Did you forget to use 'git add'?\"));\n> + \"You might want to use 'git add' on them.\"));\n> die_user_resolve(state);\n> }\n>\n> diff --git a/builtin/checkout.c b/builtin/checkout.c index bfa5419f3..05037b9b6 100644\n> --- a/builtin/checkout.c\n> +++ b/builtin/checkout.c\n> @@ -1287,7 +1287,7 @@ int cmd_checkout(int argc, const char **argv, const char *prefix)\n> */\n> if (opts.new_branch && argc == 1)\n> die(_(\"Cannot update paths and switch to branch '%s' at the same time.\\n\"\n> - \"Did you intend to checkout '%s' which can not be resolved as commit?\"),\n> + \"'%s' can not be resolved as commit, but it should.\"),\n> opts.new_branch, argv[0]);\n>\n> if (opts.force_detach)\n> diff --git a/help.c b/help.c\n> index bc6cd19cf..4658a55c6 100644\n> --- a/help.c\n> +++ b/help.c\n> @@ -411,8 +411,8 @@ const char *help_unknown_cmd(const char *cmd)\n>\n> if (SIMILAR_ENOUGH(best_similarity)) {\n> fprintf_ln(stderr,\n> - Q_(\"\\nDid you mean this?\",\n> - \"\\nDid you mean one of these?\",\n> + Q_(\"\\nThe most approaching command is\",\n> + \"\\nThe most approaching commands are\",\n> n));\n>\n> for (i = 0; i < n; i++)\n> --\n> 2.12.0\n>\n> Atos, Atos Consulting, Worldline and Canopy The Open Cloud Company are trading names used by the Atos group. The following trading entities are registered in England and Wales: Atos IT Services UK Limited (registered number 01245534), Atos Consulting Limited (registered number 04312380), Atos Worldline UK Limited (registered number 08514184) and Canopy The Open Cloud Company Limited (registration number 08011902). The registered office for each is at 4 Triton Square, Regent’s Place, London, NW1 3HG.The VAT No. for each is: GB232327983.\n>\n> This e-mail and the documents attached are confidential and intended solely for the addressee, and may contain confidential or privileged information. If you receive this e-mail in error, you are not authorised to copy, disclose, use or retain it. Please notify the sender immediately and delete this email from your systems. As emails may be intercepted, amended or lost, they are not secure. Atos therefore can accept no liability for any errors or their content. Although Atos endeavours to maintain a virus-free network, we do not warrant that this transmission is virus-free and can accept no liability for any damages resulting from any virus transmitted. The risks are deemed to be accepted by everyone who communicates with Atos by email.\n"},{"id":"318739","messageId":"1852434.EkqkZv3l6Q@cayenne","threadId":"45861","inReplyTo":"61C67DC73308BD49B2D4B65072480DBA2BDA554E@DEERLM99EZ1MSX.ww931.my-it-solutions.net","subject":"Re: [PATCH v2 1/3] usability: don't ask questions if no reply is required","fromName":"Jean-Noël AVILA","fromEmail":"jn.avila@free.fr","sentAt":"2017-05-04T09:41:06Z","receivedAt":"2017-05-04T09:41:16Z","isPatch":true,"sender":{"key":"jn.avila@free.fr","avatar":"https://avatars.githubusercontent.com/u/156172?v=4"},"body":"Le jeudi 4 mai 2017, 08:52:43 CEST Kerry, Richard a écrit :\n> \n> May I suggest that \" The most approaching commands\" doesn't make much sense as English (I don't think a command can \"approach\").\n> Perhaps it should be \" The most appropriate commands\".\n> \n> \n> Regards,\n> Richard.\n> \n\n\n\nThank you for your proposition. \"approaching\" is a frenchism doubled with google translate (sorry!). Maybe \"similar\" would also work.\n \n"},{"id":"318750","messageId":"61C67DC73308BD49B2D4B65072480DBA2BDA5654@DEERLM99EZ1MSX.ww931.my-it-solutions.net","threadId":"45861","inReplyTo":"CACBZZX77Ad120bgTxJd+jqvPEX81BEYWrXnN2TeK+UgT63816w@mail.gmail.com","subject":"RE: [PATCH v2 1/3] usability: don't ask questions if no reply is required","fromName":"Kerry, Richard","fromEmail":"richard.kerry@atos.net","sentAt":"2017-05-04T10:14:58Z","receivedAt":"2017-05-04T10:15:09Z","isPatch":true,"sender":{"key":"richard.kerry@atos.net","avatar":null},"body":"\nMy point was to ensure that where English is used on-screen it should make sense, which in this particular case it didn't (a French idiom which, on using an automatic translator, didn't make sense in English). The same of course applies to other languages used on-screen.\n\nI agree about ensuring that the application doesn't elicit a response that it won't, or can't, actually handle. A rhetorical question is fine, so long as it is clear that the program won't accept any further input.\n\nThough I don't agree about the issue of the length of words, as presented to a non-native speaker. Sometimes a longer word can be very specific in its meaning, and can be looked up in a dictionary if the reader is not familiar with it. Sometimes using shorter words can result in a less clear meaning, or perhaps be an idiomatic usage, which might be missed by a non-native speaker.\n\nRegards,\nRichard.\n\n\n\n\nRichard Kerry\nBNCS Engineer, SI SOL Telco & Media Vertical Practice\nT: +44 (0)20 3618 2669\nM: +44 (0)7812 325518\n4 Triton Square, Regent’s Place, London NW1 3HG\nrichard.kerry@atos.net\n\n\nThis e-mail and the documents attached are confidential and intended solely for the addressee; it may also be privileged. If you receive this e-mail in error, please notify the sender immediately and destroy it. As its integrity cannot be secured on the Internet, the Atos group liability cannot be triggered for the message content. Although the sender endeavours to maintain a computer virus-free network, the sender does not warrant that this transmission is virus-free and will not be liable for any damages resulting from any virus transmitted.\n\n________________________________________\nFrom: Ævar Arnfjörð Bjarmason [avarab@gmail.com]\nSent: 04 May 2017 10:09\nTo: Kerry, Richard\nCc: git@vger.kernel.org\nSubject: Re: [PATCH v2 1/3] usability: don't ask questions if no reply is required\n\nOn Thu, May 4, 2017 at 10:52 AM, Kerry, Richard wrote:\n>\n> May I suggest that \" The most approaching commands\" doesn't make much sense as English (I don't think a command can \"approach\").\n> Perhaps it should be \" The most appropriate commands\".\n\nI had the same concern, saying \"appropriate\" is IMO also confusing.\nThe point of this UI is not to point out what you should be running,\nwhich \"appropriate\" implies, but just \"we couldn't find what you\nmeant, did you mean one of these?\".\n\nI think nothing needs to change here. The whole premise here is that a\nprogram should never ask a question when you can't give an answer, I\nthink that's nonsense. There's such a thing as a rhetorical question,\nand sometimes using that form is the most obvious & succinct way to\nput things.\n\nWhich is not to say that phrasing these things as a non-question can't\nbe better, but the suggestions so far just seem more complex.\n\nAlso keep in mind that a huge part of the user base for git using the\nEnglish UI consists of non-native speakers, and when in doubt we\nshould definitely be picking simpler English like \"did you mean?\" v.s.\nalternatives with >10 character more obscure words.\n\n> Richard Kerry\n> BNCS Engineer, SI SOL Telco & Media Vertical Practice\n>\n> T: +44 (0)20 3618 2669\n> M: +44 (0)7812 325518\n> Lync: +44 (0) 20 3618 0778\n> Room G300, Stadium House, Wood Lane, London, W12 7TA\n> richard.kerry@atos.net\n>\n>\n>\n>\n> -----Original Message-----\n> From: git-owner@vger.kernel.org [mailto:git-owner@vger.kernel.org] On Behalf Of Jean-Noel Avila\n> Sent: Wednesday, May 03, 2017 10:07 PM\n> To: git@vger.kernel.org\n> Cc: rashmipai36@gmail.com; Jean-Noel Avila \n> Subject: [PATCH v2 1/3] usability: don't ask questions if no reply is required\n>\n> There has been a bug report by a corporate user that stated that \"spelling mistake of stash followed by a yes prints character 'y'\n> infinite times.\"\n>\n> This analysis was false. When the spelling of a command contains errors, the git program tries to help the user by providing candidates which are close to the unexisting command. E.g Git prints the\n> following:\n>\n> git: 'stahs' is not a git command. See 'git --help'.\n> Did you mean this?\n>\n> stash\n>\n> and then exits.\n>\n> The problem with this hint is that it is not formally indicated as an hint and the user is in fact encouraged to reply to the question, whereas the Git command is already finished.\n>\n> The user was unlucky enough that it was the command he was looking for, and replied \"yes\" on the command line, effectively launching the `yes` program.\n>\n> The initial error is that the Git programs, when launched in command-line mode (without interaction) must not ask questions, because these questions would normally require a user input as a reply while they won't handle indeed. That's a source of confusion on UX level.\n>\n> To improve the general usability of the Git suite, the following rule was applied:\n>\n> if the sentence\n> * appears in a non-interactive session\n> * is printed last before exit\n> * is a question addressing the user (\"you\")\n>\n> the sentence is turned into affirmative and proposes the option.\n>\n> The basic rewording of the question sentences has been extended to other spots found in the source.\n>\n> Requested at https://github.com/git/git-scm.com/issues/999 by rpai1\n>\n> Signed-off-by: Jean-Noel Avila \n> ---\n> builtin/am.c | 4 ++--\n> builtin/checkout.c | 2 +-\n> help.c | 4 ++--\n> 3 files changed, 5 insertions(+), 5 deletions(-)\n>\n> diff --git a/builtin/am.c b/builtin/am.c index a95dd8b4e..f5afa438d 100644\n> --- a/builtin/am.c\n> +++ b/builtin/am.c\n> @@ -1312,7 +1312,7 @@ static int parse_mail(struct am_state *state, const char *mail)\n> }\n>\n> if (is_empty_file(am_path(state, \"patch\"))) {\n> - printf_ln(_(\"Patch is empty. Was it split wrong?\"));\n> + printf_ln(_(\"Patch is empty. It may have been split wrong.\"));\n> die_user_resolve(state);\n> }\n>\n> @@ -1940,7 +1940,7 @@ static void am_resolve(struct am_state *state)\n>\n> if (unmerged_cache()) {\n> printf_ln(_(\"You still have unmerged paths in your index.\\n\"\n> - \"Did you forget to use 'git add'?\"));\n> + \"You might want to use 'git add' on them.\"));\n> die_user_resolve(state);\n> }\n>\n> diff --git a/builtin/checkout.c b/builtin/checkout.c index bfa5419f3..05037b9b6 100644\n> --- a/builtin/checkout.c\n> +++ b/builtin/checkout.c\n> @@ -1287,7 +1287,7 @@ int cmd_checkout(int argc, const char **argv, const char *prefix)\n> */\n> if (opts.new_branch && argc == 1)\n> die(_(\"Cannot update paths and switch to branch '%s' at the same time.\\n\"\n> - \"Did you intend to checkout '%s' which can not be resolved as commit?\"),\n> + \"'%s' can not be resolved as commit, but it should.\"),\n> opts.new_branch, argv[0]);\n>\n> if (opts.force_detach)\n> diff --git a/help.c b/help.c\n> index bc6cd19cf..4658a55c6 100644\n> --- a/help.c\n> +++ b/help.c\n> @@ -411,8 +411,8 @@ const char *help_unknown_cmd(const char *cmd)\n>\n> if (SIMILAR_ENOUGH(best_similarity)) {\n> fprintf_ln(stderr,\n> - Q_(\"\\nDid you mean this?\",\n> - \"\\nDid you mean one of these?\",\n> + Q_(\"\\nThe most approaching command is\",\n> + \"\\nThe most approaching commands are\",\n> n));\n>\n> for (i = 0; i < n; i++)\n> --\n> 2.12.0\n>\n> Atos, Atos Consulting, Worldline and Canopy The Open Cloud Company are trading names used by the Atos group. The following trading entities are registered in England and Wales: Atos IT Services UK Limited (registered number 01245534), Atos Consulting Limited (registered number 04312380), Atos Worldline UK Limited (registered number 08514184) and Canopy The Open Cloud Company Limited (registration number 08011902). The registered office for each is at 4 Triton Square, Regent’s Place, London, NW1 3HG.The VAT No. for each is: GB232327983.\n>\n> This e-mail and the documents attached are confidential and intended solely for the addressee, and may contain confidential or privileged information. If you receive this e-mail in error, you are not authorised to copy, disclose, use or retain it. Please notify the sender immediately and delete this email from your systems. As emails may be intercepted, amended or lost, they are not secure. Atos therefore can accept no liability for any errors or their content. Although Atos endeavours to maintain a virus-free network, we do not warrant that this transmission is virus-free and can accept no liability for any damages resulting from any virus transmitted. The risks are deemed to be accepted by everyone who communicates with Atos by email.\nAtos, Atos Consulting, Worldline and Canopy The Open Cloud Company are trading names used by the Atos group. The following trading entities are registered in England and Wales: Atos IT Services UK Limited (registered number 01245534), Atos Consulting Limited (registered number 04312380), Atos Worldline UK Limited (registered number 08514184) and Canopy The Open Cloud Company Limited (registration number 08011902). The registered office for each is at 4 Triton Square, Regent’s Place, London, NW1 3HG.The VAT No. for each is: GB232327983.\n\nThis e-mail and the documents attached are confidential and intended solely for the addressee, and may contain confidential or privileged information. If you receive this e-mail in error, you are not authorised to copy, disclose, use or retain it. Please notify the sender immediately and delete this email from your systems. As emails may be intercepted, amended or lost, they are not secure. Atos therefore can accept no liability for any errors or their content. Although Atos endeavours to maintain a virus-free network, we do not warrant that this transmission is virus-free and can accept no liability for any damages resulting from any virus transmitted. The risks are deemed to be accepted by everyone who communicates with Atos by email.\n"},{"id":"319172","messageId":"3081807.Ek7CimHVI7@cayenne","threadId":"45861","inReplyTo":"61C67DC73308BD49B2D4B65072480DBA2BDA5654@DEERLM99EZ1MSX.ww931.my-it-solutions.net","subject":"Re: [PATCH v2 1/3] usability: don't ask questions if no reply is required","fromName":"Jean-Noël AVILA","fromEmail":"jn.avila@free.fr","sentAt":"2017-05-09T08:18:11Z","receivedAt":"2017-05-09T08:18:23Z","isPatch":true,"sender":{"key":"jn.avila@free.fr","avatar":"https://avatars.githubusercontent.com/u/156172?v=4"},"body":"Le jeudi 4 mai 2017, 10:14:58 CEST Kerry, Richard a écrit :\n> \n> My point was to ensure that where English is used on-screen it should make sense, which in this particular case it didn't (a French idiom which, on using an automatic translator, didn't make sense in English). The same of course applies to other languages used on-screen.\n> \n> I agree about ensuring that the application doesn't elicit a response that it won't, or can't, actually handle. A rhetorical question is fine, so long as it is clear that the program won't accept any further input.\n> \n> Though I don't agree about the issue of the length of words, as presented to a non-native speaker. Sometimes a longer word can be very specific in its meaning, and can be looked up in a dictionary if the reader is not familiar with it. Sometimes using shorter words can result in a less clear meaning, or perhaps be an idiomatic usage, which might be missed by a non-native speaker.\n> \n\nThanks. So what's the status of this patch series? I don't buy the idea of rhetorical HMI. That's a sure way to confuse non-native speakers. Please note that I kept the questions when there is a following text. Only questions addressing the user at the end of output have been rephrased.\n\nFor the \"do you mean\" questions, the proposition would then simply be: \"the most similar command is:\" or \"the most similar commands are:\".\n\nand then what about the other patches?\n\nThanks\n\n\n> Regards,\n> Richard.\n> \n> \n> \n> \n> Richard Kerry\n> BNCS Engineer, SI SOL Telco & Media Vertical Practice\n> T: +44 (0)20 3618 2669\n> M: +44 (0)7812 325518\n> 4 Triton Square, Regent’s Place, London NW1 3HG\n> richard.kerry@atos.net\n> \n> \n> This e-mail and the documents attached are confidential and intended solely for the addressee; it may also be privileged. If you receive this e-mail in error, please notify the sender immediately and destroy it. As its integrity cannot be secured on the Internet, the Atos group liability cannot be triggered for the message content. Although the sender endeavours to maintain a computer virus-free network, the sender does not warrant that this transmission is virus-free and will not be liable for any damages resulting from any virus transmitted.\n> \n> ________________________________________\n> From: Ævar Arnfjörð Bjarmason [avarab@gmail.com]\n> Sent: 04 May 2017 10:09\n> To: Kerry, Richard\n> Cc: git@vger.kernel.org\n> Subject: Re: [PATCH v2 1/3] usability: don't ask questions if no reply is required\n> \n> On Thu, May 4, 2017 at 10:52 AM, Kerry, Richard wrote:\n> >\n> > May I suggest that \" The most approaching commands\" doesn't make much sense as English (I don't think a command can \"approach\").\n> > Perhaps it should be \" The most appropriate commands\".\n> \n> I had the same concern, saying \"appropriate\" is IMO also confusing.\n> The point of this UI is not to point out what you should be running,\n> which \"appropriate\" implies, but just \"we couldn't find what you\n> meant, did you mean one of these?\".\n> \n> I think nothing needs to change here. The whole premise here is that a\n> program should never ask a question when you can't give an answer, I\n> think that's nonsense. There's such a thing as a rhetorical question,\n> and sometimes using that form is the most obvious & succinct way to\n> put things.\n> \n> Which is not to say that phrasing these things as a non-question can't\n> be better, but the suggestions so far just seem more complex.\n> \n> Also keep in mind that a huge part of the user base for git using the\n> English UI consists of non-native speakers, and when in doubt we\n> should definitely be picking simpler English like \"did you mean?\" v.s.\n> alternatives with >10 character more obscure words.\n> \n> > Richard Kerry\n> > BNCS Engineer, SI SOL Telco & Media Vertical Practice\n> >\n> > T: +44 (0)20 3618 2669\n> > M: +44 (0)7812 325518\n> > Lync: +44 (0) 20 3618 0778\n> > Room G300, Stadium House, Wood Lane, London, W12 7TA\n> > richard.kerry@atos.net\n> >\n> >\n> >\n> >\n> > -----Original Message-----\n> > From: git-owner@vger.kernel.org [mailto:git-owner@vger.kernel.org] On Behalf Of Jean-Noel Avila\n> > Sent: Wednesday, May 03, 2017 10:07 PM\n> > To: git@vger.kernel.org\n> > Cc: rashmipai36@gmail.com; Jean-Noel Avila \n> > Subject: [PATCH v2 1/3] usability: don't ask questions if no reply is required\n> >\n> > There has been a bug report by a corporate user that stated that \"spelling mistake of stash followed by a yes prints character 'y'\n> > infinite times.\"\n> >\n> > This analysis was false. When the spelling of a command contains errors, the git program tries to help the user by providing candidates which are close to the unexisting command. E.g Git prints the\n> > following:\n> >\n> > git: 'stahs' is not a git command. See 'git --help'.\n> > Did you mean this?\n> >\n> > stash\n> >\n> > and then exits.\n> >\n> > The problem with this hint is that it is not formally indicated as an hint and the user is in fact encouraged to reply to the question, whereas the Git command is already finished.\n> >\n> > The user was unlucky enough that it was the command he was looking for, and replied \"yes\" on the command line, effectively launching the `yes` program.\n> >\n> > The initial error is that the Git programs, when launched in command-line mode (without interaction) must not ask questions, because these questions would normally require a user input as a reply while they won't handle indeed. That's a source of confusion on UX level.\n> >\n> > To improve the general usability of the Git suite, the following rule was applied:\n> >\n> > if the sentence\n> > * appears in a non-interactive session\n> > * is printed last before exit\n> > * is a question addressing the user (\"you\")\n> >\n> > the sentence is turned into affirmative and proposes the option.\n> >\n> > The basic rewording of the question sentences has been extended to other spots found in the source.\n> >\n> > Requested at https://github.com/git/git-scm.com/issues/999 by rpai1\n> >\n> > Signed-off-by: Jean-Noel Avila \n> > ---\n> > builtin/am.c | 4 ++--\n> > builtin/checkout.c | 2 +-\n> > help.c | 4 ++--\n> > 3 files changed, 5 insertions(+), 5 deletions(-)\n> >\n> > diff --git a/builtin/am.c b/builtin/am.c index a95dd8b4e..f5afa438d 100644\n> > --- a/builtin/am.c\n> > +++ b/builtin/am.c\n> > @@ -1312,7 +1312,7 @@ static int parse_mail(struct am_state *state, const char *mail)\n> > }\n> >\n> > if (is_empty_file(am_path(state, \"patch\"))) {\n> > - printf_ln(_(\"Patch is empty. Was it split wrong?\"));\n> > + printf_ln(_(\"Patch is empty. It may have been split wrong.\"));\n> > die_user_resolve(state);\n> > }\n> >\n> > @@ -1940,7 +1940,7 @@ static void am_resolve(struct am_state *state)\n> >\n> > if (unmerged_cache()) {\n> > printf_ln(_(\"You still have unmerged paths in your index.\\n\"\n> > - \"Did you forget to use 'git add'?\"));\n> > + \"You might want to use 'git add' on them.\"));\n> > die_user_resolve(state);\n> > }\n> >\n> > diff --git a/builtin/checkout.c b/builtin/checkout.c index bfa5419f3..05037b9b6 100644\n> > --- a/builtin/checkout.c\n> > +++ b/builtin/checkout.c\n> > @@ -1287,7 +1287,7 @@ int cmd_checkout(int argc, const char **argv, const char *prefix)\n> > */\n> > if (opts.new_branch && argc == 1)\n> > die(_(\"Cannot update paths and switch to branch '%s' at the same time.\\n\"\n> > - \"Did you intend to checkout '%s' which can not be resolved as commit?\"),\n> > + \"'%s' can not be resolved as commit, but it should.\"),\n> > opts.new_branch, argv[0]);\n> >\n> > if (opts.force_detach)\n> > diff --git a/help.c b/help.c\n> > index bc6cd19cf..4658a55c6 100644\n> > --- a/help.c\n> > +++ b/help.c\n> > @@ -411,8 +411,8 @@ const char *help_unknown_cmd(const char *cmd)\n> >\n> > if (SIMILAR_ENOUGH(best_similarity)) {\n> > fprintf_ln(stderr,\n> > - Q_(\"\\nDid you mean this?\",\n> > - \"\\nDid you mean one of these?\",\n> > + Q_(\"\\nThe most approaching command is\",\n> > + \"\\nThe most approaching commands are\",\n> > n));\n> >\n> > for (i = 0; i < n; i++)\n> > --\n> > 2.12.0\n> >\n> > Atos, Atos Consulting, Worldline and Canopy The Open Cloud Company are trading names used by the Atos group. The following trading entities are registered in England and Wales: Atos IT Services UK Limited (registered number 01245534), Atos Consulting Limited (registered number 04312380), Atos Worldline UK Limited (registered number 08514184) and Canopy The Open Cloud Company Limited (registration number 08011902). The registered office for each is at 4 Triton Square, Regent’s Place, London, NW1 3HG.The VAT No. for each is: GB232327983.\n> >\n> > This e-mail and the documents attached are confidential and intended solely for the addressee, and may contain confidential or privileged information. If you receive this e-mail in error, you are not authorised to copy, disclose, use or retain it. Please notify the sender immediately and delete this email from your systems. As emails may be intercepted, amended or lost, they are not secure. Atos therefore can accept no liability for any errors or their content. Although Atos endeavours to maintain a virus-free network, we do not warrant that this transmission is virus-free and can accept no liability for any damages resulting from any virus transmitted. The risks are deemed to be accepted by everyone who communicates with Atos by email.\n> Atos, Atos Consulting, Worldline and Canopy The Open Cloud Company are trading names used by the Atos group. The following trading entities are registered in England and Wales: Atos IT Services UK Limited (registered number 01245534), Atos Consulting Limited (registered number 04312380), Atos Worldline UK Limited (registered number 08514184) and Canopy The Open Cloud Company Limited (registration number 08011902). The registered office for each is at 4 Triton Square, Regent’s Place, London, NW1 3HG.The VAT No. for each is: GB232327983.\n> \n> This e-mail and the documents attached are confidential and intended solely for the addressee, and may contain confidential or privileged information. If you receive this e-mail in error, you are not authorised to copy, disclose, use or retain it. Please notify the sender immediately and delete this email from your systems. As emails may be intercepted, amended or lost, they are not secure. Atos therefore can accept no liability for any errors or their content. Although Atos endeavours to maintain a virus-free network, we do not warrant that this transmission is virus-free and can accept no liability for any damages resulting from any virus transmitted. The risks are deemed to be accepted by everyone who communicates with Atos by email.\n> \n\n\n"},{"id":"319173","messageId":"CACBZZX7kDx_F=b=efuH=m786SEOTy7EZ659tw7a=QpLWojaB5Q@mail.gmail.com","threadId":"45861","inReplyTo":"3081807.Ek7CimHVI7@cayenne","subject":"Re: [PATCH v2 1/3] usability: don't ask questions if no reply is required","fromName":"Ævar Arnfjörð Bjarmason","fromEmail":"avarab@gmail.com","sentAt":"2017-05-09T09:21:27Z","receivedAt":"2017-05-09T09:21:57Z","isPatch":true,"sender":{"key":"avarab@gmail.com","avatar":"https://avatars.githubusercontent.com/u/45301?v=4"},"body":"On Tue, May 9, 2017 at 10:18 AM, Jean-Noël AVILA wrote:\n> Le jeudi 4 mai 2017, 10:14:58 CEST Kerry, Richard a écrit :\n>>\n>> My point was to ensure that where English is used on-screen it should make sense, which in this particular case it didn't (a French idiom which, on using an automatic translator, didn't make sense in English). The same of course applies to other languages used on-screen.\n>>\n>> I agree about ensuring that the application doesn't elicit a response that it won't, or can't, actually handle. A rhetorical question is fine, so long as it is clear that the program won't accept any further input.\n>>\n>> Though I don't agree about the issue of the length of words, as presented to a non-native speaker. Sometimes a longer word can be very specific in its meaning, and can be looked up in a dictionary if the reader is not familiar with it. Sometimes using shorter words can result in a less clear meaning, or perhaps be an idiomatic usage, which might be missed by a non-native speaker.\n>>\n>\n> Thanks. So what's the status of this patch series? I don't buy the idea of rhetorical HMI. That's a sure way to confuse non-native speakers. Please note that I kept the questions when there is a following text. Only questions addressing the user at the end of output have been rephrased.\n>\n> For the \"do you mean\" questions, the proposition would then simply be: \"the most similar command is:\" or \"the most similar commands are:\".\n>\n> and then what about the other patches?\n\nWhen you submit patches you can monitor the next \"What's cooking\" mail\nfor the status. See \"ja/do-not...\" here:\nhttps://public-inbox.org/git/xmqqlgq77pse.fsf@gitster.mtv.corp.google.com/\n\nIt got picked up for the \"pu\" branch. You can fetch git.git and see it there.\n\nMy feedback on the 3:\n\n* 1/3: Mostly covered above. I did notice after my last comment that\nevery time gcc wants to suggest you should do something different\n(e.g. misspelled variable or macro) it'll say \"did you mean?\" similar\nto what git does now.\n\nWhile I think this is a rather tragic story of *nix usability (\"user\ngets asked a question, types yes, gets a few GB/s of y as output\") the\nmain UX problem is surely that the user in question didn't understand\nfrom the terminal output when the program had exited & wasn't\ninteractive anymore.\n\nBut overall this seems like optimizing for a really obscure edge case\nat the expense of making the wording more clever. I don't think \"did\nyou mean?\" will confuse non-native speakers, as the bug report shows\nthe user in question has a reasonable command of English, they're\nfundimentally confused about how the shell interface works.\n\n* 2/3: Looks great, surprised it took so long for someone to remove\nthat cutsey but bad message.\n\n* 3/3: I think this partly makes things slightly worse. I.e. now you\nget a specific error message about refs being missing, after it shows\nyou the entire usage info, so you don't know if you e.g. misspelled a\ncommand-line flag or what. I couldn't find any pattern in the existing\nshell scripts for \"print usage with custom message\" thoug.\n\n>> Regards,\n>> Richard.\n>>\n>>\n>>\n>>\n>> Richard Kerry\n>> BNCS Engineer, SI SOL Telco & Media Vertical Practice\n>> T: +44 (0)20 3618 2669\n>> M: +44 (0)7812 325518\n>> 4 Triton Square, Regent’s Place, London NW1 3HG\n>> richard.kerry@atos.net\n>>\n>>\n>> This e-mail and the documents attached are confidential and intended solely for the addressee; it may also be privileged. If you receive this e-mail in error, please notify the sender immediately and destroy it. As its integrity cannot be secured on the Internet, the Atos group liability cannot be triggered for the message content. Although the sender endeavours to maintain a computer virus-free network, the sender does not warrant that this transmission is virus-free and will not be liable for any damages resulting from any virus transmitted.\n>>\n>> ________________________________________\n>> From: Ævar Arnfjörð Bjarmason [avarab@gmail.com]\n>> Sent: 04 May 2017 10:09\n>> To: Kerry, Richard\n>> Cc: git@vger.kernel.org\n>> Subject: Re: [PATCH v2 1/3] usability: don't ask questions if no reply is required\n>>\n>> On Thu, May 4, 2017 at 10:52 AM, Kerry, Richard wrote:\n>> >\n>> > May I suggest that \" The most approaching commands\" doesn't make much sense as English (I don't think a command can \"approach\").\n>> > Perhaps it should be \" The most appropriate commands\".\n>>\n>> I had the same concern, saying \"appropriate\" is IMO also confusing.\n>> The point of this UI is not to point out what you should be running,\n>> which \"appropriate\" implies, but just \"we couldn't find what you\n>> meant, did you mean one of these?\".\n>>\n>> I think nothing needs to change here. The whole premise here is that a\n>> program should never ask a question when you can't give an answer, I\n>> think that's nonsense. There's such a thing as a rhetorical question,\n>> and sometimes using that form is the most obvious & succinct way to\n>> put things.\n>>\n>> Which is not to say that phrasing these things as a non-question can't\n>> be better, but the suggestions so far just seem more complex.\n>>\n>> Also keep in mind that a huge part of the user base for git using the\n>> English UI consists of non-native speakers, and when in doubt we\n>> should definitely be picking simpler English like \"did you mean?\" v.s.\n>> alternatives with >10 character more obscure words.\n>>\n>> > Richard Kerry\n>> > BNCS Engineer, SI SOL Telco & Media Vertical Practice\n>> >\n>> > T: +44 (0)20 3618 2669\n>> > M: +44 (0)7812 325518\n>> > Lync: +44 (0) 20 3618 0778\n>> > Room G300, Stadium House, Wood Lane, London, W12 7TA\n>> > richard.kerry@atos.net\n>> >\n>> >\n>> >\n>> >\n>> > -----Original Message-----\n>> > From: git-owner@vger.kernel.org [mailto:git-owner@vger.kernel.org] On Behalf Of Jean-Noel Avila\n>> > Sent: Wednesday, May 03, 2017 10:07 PM\n>> > To: git@vger.kernel.org\n>> > Cc: rashmipai36@gmail.com; Jean-Noel Avila \n>> > Subject: [PATCH v2 1/3] usability: don't ask questions if no reply is required\n>> >\n>> > There has been a bug report by a corporate user that stated that \"spelling mistake of stash followed by a yes prints character 'y'\n>> > infinite times.\"\n>> >\n>> > This analysis was false. When the spelling of a command contains errors, the git program tries to help the user by providing candidates which are close to the unexisting command. E.g Git prints the\n>> > following:\n>> >\n>> > git: 'stahs' is not a git command. See 'git --help'.\n>> > Did you mean this?\n>> >\n>> > stash\n>> >\n>> > and then exits.\n>> >\n>> > The problem with this hint is that it is not formally indicated as an hint and the user is in fact encouraged to reply to the question, whereas the Git command is already finished.\n>> >\n>> > The user was unlucky enough that it was the command he was looking for, and replied \"yes\" on the command line, effectively launching the `yes` program.\n>> >\n>> > The initial error is that the Git programs, when launched in command-line mode (without interaction) must not ask questions, because these questions would normally require a user input as a reply while they won't handle indeed. That's a source of confusion on UX level.\n>> >\n>> > To improve the general usability of the Git suite, the following rule was applied:\n>> >\n>> > if the sentence\n>> > * appears in a non-interactive session\n>> > * is printed last before exit\n>> > * is a question addressing the user (\"you\")\n>> >\n>> > the sentence is turned into affirmative and proposes the option.\n>> >\n>> > The basic rewording of the question sentences has been extended to other spots found in the source.\n>> >\n>> > Requested at https://github.com/git/git-scm.com/issues/999 by rpai1\n>> >\n>> > Signed-off-by: Jean-Noel Avila \n>> > ---\n>> > builtin/am.c | 4 ++--\n>> > builtin/checkout.c | 2 +-\n>> > help.c | 4 ++--\n>> > 3 files changed, 5 insertions(+), 5 deletions(-)\n>> >\n>> > diff --git a/builtin/am.c b/builtin/am.c index a95dd8b4e..f5afa438d 100644\n>> > --- a/builtin/am.c\n>> > +++ b/builtin/am.c\n>> > @@ -1312,7 +1312,7 @@ static int parse_mail(struct am_state *state, const char *mail)\n>> > }\n>> >\n>> > if (is_empty_file(am_path(state, \"patch\"))) {\n>> > - printf_ln(_(\"Patch is empty. Was it split wrong?\"));\n>> > + printf_ln(_(\"Patch is empty. It may have been split wrong.\"));\n>> > die_user_resolve(state);\n>> > }\n>> >\n>> > @@ -1940,7 +1940,7 @@ static void am_resolve(struct am_state *state)\n>> >\n>> > if (unmerged_cache()) {\n>> > printf_ln(_(\"You still have unmerged paths in your index.\\n\"\n>> > - \"Did you forget to use 'git add'?\"));\n>> > + \"You might want to use 'git add' on them.\"));\n>> > die_user_resolve(state);\n>> > }\n>> >\n>> > diff --git a/builtin/checkout.c b/builtin/checkout.c index bfa5419f3..05037b9b6 100644\n>> > --- a/builtin/checkout.c\n>> > +++ b/builtin/checkout.c\n>> > @@ -1287,7 +1287,7 @@ int cmd_checkout(int argc, const char **argv, const char *prefix)\n>> > */\n>> > if (opts.new_branch && argc == 1)\n>> > die(_(\"Cannot update paths and switch to branch '%s' at the same time.\\n\"\n>> > - \"Did you intend to checkout '%s' which can not be resolved as commit?\"),\n>> > + \"'%s' can not be resolved as commit, but it should.\"),\n>> > opts.new_branch, argv[0]);\n>> >\n>> > if (opts.force_detach)\n>> > diff --git a/help.c b/help.c\n>> > index bc6cd19cf..4658a55c6 100644\n>> > --- a/help.c\n>> > +++ b/help.c\n>> > @@ -411,8 +411,8 @@ const char *help_unknown_cmd(const char *cmd)\n>> >\n>> > if (SIMILAR_ENOUGH(best_similarity)) {\n>> > fprintf_ln(stderr,\n>> > - Q_(\"\\nDid you mean this?\",\n>> > - \"\\nDid you mean one of these?\",\n>> > + Q_(\"\\nThe most approaching command is\",\n>> > + \"\\nThe most approaching commands are\",\n>> > n));\n>> >\n>> > for (i = 0; i < n; i++)\n>> > --\n>> > 2.12.0\n>> >\n>> > Atos, Atos Consulting, Worldline and Canopy The Open Cloud Company are trading names used by the Atos group. The following trading entities are registered in England and Wales: Atos IT Services UK Limited (registered number 01245534), Atos Consulting Limited (registered number 04312380), Atos Worldline UK Limited (registered number 08514184) and Canopy The Open Cloud Company Limited (registration number 08011902). The registered office for each is at 4 Triton Square, Regent’s Place, London, NW1 3HG.The VAT No. for each is: GB232327983.\n>> >\n>> > This e-mail and the documents attached are confidential and intended solely for the addressee, and may contain confidential or privileged information. If you receive this e-mail in error, you are not authorised to copy, disclose, use or retain it. Please notify the sender immediately and delete this email from your systems. As emails may be intercepted, amended or lost, they are not secure. Atos therefore can accept no liability for any errors or their content. Although Atos endeavours to maintain a virus-free network, we do not warrant that this transmission is virus-free and can accept no liability for any damages resulting from any virus transmitted. The risks are deemed to be accepted by everyone who communicates with Atos by email.\n>> Atos, Atos Consulting, Worldline and Canopy The Open Cloud Company are trading names used by the Atos group. The following trading entities are registered in England and Wales: Atos IT Services UK Limited (registered number 01245534), Atos Consulting Limited (registered number 04312380), Atos Worldline UK Limited (registered number 08514184) and Canopy The Open Cloud Company Limited (registration number 08011902). The registered office for each is at 4 Triton Square, Regent’s Place, London, NW1 3HG.The VAT No. for each is: GB232327983.\n>>\n>> This e-mail and the documents attached are confidential and intended solely for the addressee, and may contain confidential or privileged information. If you receive this e-mail in error, you are not authorised to copy, disclose, use or retain it. Please notify the sender immediately and delete this email from your systems. As emails may be intercepted, amended or lost, they are not secure. Atos therefore can accept no liability for any errors or their content. Although Atos endeavours to maintain a virus-free network, we do not warrant that this transmission is virus-free and can accept no liability for any damages resulting from any virus transmitted. The risks are deemed to be accepted by everyone who communicates with Atos by email.\n>>\n>\n>\n"},{"id":"319314","messageId":"xmqqa86kccca.fsf@gitster.mtv.corp.google.com","threadId":"45861","inReplyTo":"20170503210726.24121-1-jn.avila@free.fr","subject":"Re: [PATCH v2 1/3] usability: don't ask questions if no reply is required","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2017-05-11T03:16:21Z","receivedAt":"2017-05-11T03:16:30Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Jean-Noel Avila writes:\n\n> diff --git a/builtin/am.c b/builtin/am.c\n> index a95dd8b4e..f5afa438d 100644\n> --- a/builtin/am.c\n> +++ b/builtin/am.c\n> @@ -1312,7 +1312,7 @@ static int parse_mail(struct am_state *state, const char *mail)\n> \t}\n> \n> \tif (is_empty_file(am_path(state, \"patch\"))) {\n> -\t\tprintf_ln(_(\"Patch is empty. Was it split wrong?\"));\n> +\t\tprintf_ln(_(\"Patch is empty. It may have been split wrong.\"));\n> \t\tdie_user_resolve(state);\n> \t}\n\nWhile I do not belong to \"we should feel free to ask rhetorical\nquestions\" camp, I do not mind this particular rewrite. An obvious\nalternative is just to stop the sentence with \"Patch is empty.\"\n\nAt this point in the code, we do not even know why we are seeing an\nempty patch, and \"perhaps it was incorrectly split\" is not a\nparticularly useful idle speculation that would help the user who\nsees it.\n\n> @@ -1940,7 +1940,7 @@ static void am_resolve(struct am_state *state)\n> \n> \tif (unmerged_cache()) {\n> \t\tprintf_ln(_(\"You still have unmerged paths in your index.\\n\"\n> -\t\t\t\"Did you forget to use 'git add'?\"));\n> +\t\t\t\"You might want to use 'git add' on them.\"));\n\nThis case is *not* an \"rhetorical question is the most succinct way\nto convey the information\" situation; I think this rewrite is a\ndefinite improvement. \"You might want to 'git add' them\" may be\nmore succinct, though.\n\n> diff --git a/builtin/checkout.c b/builtin/checkout.c\n> index bfa5419f3..05037b9b6 100644\n> --- a/builtin/checkout.c\n> +++ b/builtin/checkout.c\n> @@ -1287,7 +1287,7 @@ int cmd_checkout(int argc, const char **argv, const char *prefix)\n> \t\t */\n> \t\tif (opts.new_branch && argc == 1)\n> \t\t\tdie(_(\"Cannot update paths and switch to branch '%s' at the same time.\\n\"\n> -\t\t\t \"Did you intend to checkout '%s' which can not be resolved as commit?\"),\n> +\t\t\t \"'%s' can not be resolved as commit, but it should.\"),\n\nI am not sure a firm statement \"but it should\" is an improvement.\nThis message is given when the user says:\n\n $ git checkout -b newone naster\n\nAnd \"but it should\" is appropriate when it is a mistyped \"I want to\ncreate and checkout 'newone' branch at the same commit as 'master'\nbranch\", i.e.\n\n $ git checkout -b newone master\n\nThe reason why the message begins with \"Cannot update paths and ...\"\nis because it could be a mistyped \"I want to grab the file 'naster'\nout of 'newone' branch\", i.e. the user meant to say this:\n\n $ git checkout newone naster\n\nIOW, the current error message is hedging its bets, because it does\nnot want to exclude the possibility that \"-b\" is there by mistake\n(as opposed to 'naster' is the typo).\n\nIf we ignore that possibility and assume that 'naster' is the typo\n(iow, the user did mean \"-b\"), then your updated message makes\nsense. But if we commit to \"the user meant -b\", we could make the\nmessage even more helpful by being more direct, e.g.\n\n\tdie(\"'%s' is not a commit and a branch '%s' cannot be created from it\",\n\t argv[0], opts.new_branch);\n\n> diff --git a/help.c b/help.c\n> index bc6cd19cf..4658a55c6 100644\n> --- a/help.c\n> +++ b/help.c\n> @@ -411,8 +411,8 @@ const char *help_unknown_cmd(const char *cmd)\n> \n> \tif (SIMILAR_ENOUGH(best_similarity)) {\n> \t\tfprintf_ln(stderr,\n> -\t\t\t Q_(\"\\nDid you mean this?\",\n> -\t\t\t \"\\nDid you mean one of these?\",\n> +\t\t\t Q_(\"\\nThe most approaching command is\",\n> +\t\t\t \"\\nThe most approaching commands are\",\n> \t\t\t n));\n\nWith \"closest\" or \"most similar\", as others pointed out, I think\nthis may be an improvement.\n\nThanks.\n"},{"id":"319315","messageId":"xmqq60h8cay3.fsf@gitster.mtv.corp.google.com","threadId":"45861","inReplyTo":"20170503210726.24121-2-jn.avila@free.fr","subject":"Re: [PATCH v2 2/3] read-tree -m: make error message for merging 0 trees less smart aleck","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2017-05-11T03:46:28Z","receivedAt":"2017-05-11T03:46:41Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Jean-Noel Avila writes:\n\n> \"git read-tree -m\" requires a tree argument to name the tree to be\n> merged in. Git uses a cutesy error message to say so and why:\n>\n> $ git read-tree -m\n> warning: read-tree: emptying the index with no arguments is\n> deprecated; use --empty\n> fatal: just how do you expect me to merge 0 trees?\n> $ git read-tree -m --empty\n> fatal: just how do you expect me to merge 0 trees?\n\nThis shows another issue. The \"emptying ... is deprecated\" message\nshouldn't be given when -m is present.\n\nI am not saying that that needs to be fixed by you and/or as a part\nof this patch. Just something I noticed while reviewing the patch.\n\n> Merging\n> -------\n> -If `-m` is specified, 'git read-tree' can perform 3 kinds of\n> -merge, a single tree merge if only 1 tree is given, a\n> -fast-forward merge with 2 trees, or a 3-way merge if 3 trees are\n> -provided.\n> +If `-m` is specified, at least one tree must be given on the command\n> +line. 'git read-tree' can perform 3 kinds of merge, a single tree\n> +merge if only 1 tree is given, a fast-forward merge with 2 trees, or a\n> +3-way merge if 3 trees are provided.\n\nIt may not incorrect per-se, but the existing enumeration already\nsay 1, 2 and 3 are the valid choices, so \"at least one\" may be\nredundant.\n\nOne incorrectness that needs to be changed is \"if 3 trees are\nprovided\"; it is \"if 3 or more trees\". Again, not the topic of your\nchange, but this one you may want to address while you are at it.\n\n> \tif (opts.merge) {\n> -\t\tif (stage < 2)\n> -\t\t\tdie(\"just how do you expect me to merge %d trees?\", stage-1);\n> \t\tswitch (stage - 1) {\n> +\t\tcase 0:\n\nCould \"stage\" be 0 (or negative) when we come here? If so, this rewrite\nmay no longer diagnose the error correctly in such a case.\n\n\t... goes and looks ...\n\nI think it begins with either 0 or 1 and then only counts up, so we\nshould be safe. Rolling it in the switch() like this patch does\nmakes it easier to follow what is going on, I think.\n\n> +\t\t\tdie(\"you must specify at least one tree to merge\");\n> +\t\t\tbreak;\n> \t\tcase 1:\n> \t\t\topts.fn = opts.prefix ? bind_merge : oneway_merge;\n> \t\t\tbreak;\n\nThanks.\n\n"},{"id":"319316","messageId":"xmqq1srwcamw.fsf@gitster.mtv.corp.google.com","threadId":"45861","inReplyTo":"20170503210726.24121-3-jn.avila@free.fr","subject":"Re: [PATCH v2 3/3] git-filter-branch: make the error msg when missing branch more open","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2017-05-11T03:53:11Z","receivedAt":"2017-05-11T03:53:20Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Jean-Noel Avila writes:\n\n> git-filter-branch requires the specification of a branch by one way or\n> another. If no branch appears to have been specified, we know the user\n> got the usage wrong but we don't know what they were trying to do ---\n> e.g. maybe they specified the ref to rewrite but in the wrong place.\n>\n> The safest solution is to just print the usage in this case.\n>\n> Signed-off-by: Jean-Noel Avila \n> ---\n> git-filter-branch.sh | 2 +-\n> 1 file changed, 1 insertion(+), 1 deletion(-)\n>\n> diff --git a/git-filter-branch.sh b/git-filter-branch.sh\n> index 2b8cdba15..bda2bae23 100755\n> --- a/git-filter-branch.sh\n> +++ b/git-filter-branch.sh\n> @@ -239,7 +239,7 @@ git rev-parse --no-flags --revs-only --symbolic-full-name \\\n> sed -e '/^^/d' \"$tempdir\"/raw-heads >\"$tempdir\"/heads\n> \n> test -s \"$tempdir\"/heads ||\n> -\tdie \"Which ref do you want to rewrite?\"\n> +\tusage\n> \n> GIT_INDEX_FILE=\"$(pwd)/../index\"\n> export GIT_INDEX_FILE\n\nI tend to agree with Ævar on this one. It is not apparent to the\nend user after this change what exactly was wrong in the input; for\nthat matter, it is not even clear that the command is refusing to\nrun because it found problem with the input. \n\nTrying to move away from asking \"I didn't get that, what did you\nmean?\" is one thing, and that can be done by saying \"no ref to\nrewrite given\" or something. We may want to make it into a more\n\"positive\" nudge, telling the user what to do, e.g. \"give me the\nrefs to rewrite.\"\n\nThanks.\n\n\n\n"},{"id":"319317","messageId":"xmqqwp9oau9x.fsf_-_@gitster.mtv.corp.google.com","threadId":"45861","inReplyTo":"xmqq60h8cay3.fsf@gitster.mtv.corp.google.com","subject":"[PATCH] read-tree: \"read-tree -m --empty\" does not make sense","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2017-05-11T04:31:54Z","receivedAt":"2017-05-11T04:32:05Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"fb1bb965 (\"read-tree: deprecate syntax without tree-ish args\",\n2010-09-10) wanted to deprecate \"git read-tree\" without any tree,\nwhich used to be the way to empty the index, and encourage use of\n\"git read-tree --empty\" instead. \n\nHowever, when used with \"-m\", \"--empty\" does not make any sense,\neither, simply because merging 0 trees will result in a different\nerror anyway.\n\nOmit the deprecation warning and let the code to emit real error\nmessage diagnose the error.\n\nSigned-off-by: Junio C Hamano \n---\n\n Junio C Hamano writes:\n\n > Jean-Noel Avila writes:\n >\n >> \"git read-tree -m\" requires a tree argument to name the tree to be\n >> merged in. Git uses a cutesy error message to say so and why:\n >>\n >> $ git read-tree -m\n >> warning: read-tree: emptying the index with no arguments is\n >> deprecated; use --empty\n >> fatal: just how do you expect me to merge 0 trees?\n >> $ git read-tree -m --empty\n >> fatal: just how do you expect me to merge 0 trees?\n >\n > This shows another issue. The \"emptying ... is deprecated\" message\n > shouldn't be given when -m is present.\n >\n > I am not saying that that needs to be fixed by you and/or as a part\n > of this patch. Just something I noticed while reviewing the patch.\n\n builtin/read-tree.c | 2 +-\n 1 file changed, 1 insertion(+), 1 deletion(-)\n\ndiff --git a/builtin/read-tree.c b/builtin/read-tree.c\nindex 23e212ee8c..284de743c3 100644\n--- a/builtin/read-tree.c\n+++ b/builtin/read-tree.c\n@@ -210,7 +210,7 @@ int cmd_read_tree(int argc, const char **argv, const char *unused_prefix)\n \t\t\tdie(\"failed to unpack tree object %s\", arg);\n \t\tstage++;\n \t}\n-\tif (nr_trees == 0 && !read_empty)\n+\tif (!nr_trees && !read_empty && !opts.merge)\n \t\twarning(\"read-tree: emptying the index with no arguments is deprecated; use --empty\");\n \telse if (nr_trees > 0 && read_empty)\n \t\tdie(\"passing trees as arguments contradicts --empty\");\n-- \n2.13.0-336-gf73534b083\n\n"},{"id":"319385","messageId":"61C67DC73308BD49B2D4B65072480DBA2BDAB97D@DEERLM99EZ1MSX.ww931.my-it-solutions.net","threadId":"45861","inReplyTo":"xmqqa86kccca.fsf@gitster.mtv.corp.google.com","subject":"RE: [PATCH v2 1/3] usability: don't ask questions if no reply is required","fromName":"Kerry, Richard","fromEmail":"richard.kerry@atos.net","sentAt":"2017-05-11T10:10:05Z","receivedAt":"2017-05-11T10:10:20Z","isPatch":true,"sender":{"key":"richard.kerry@atos.net","avatar":null},"body":"Some more grammar/usage notes .....\n\n> -----Original Message-----\n> From: git-owner@vger.kernel.org [mailto:git-owner@vger.kernel.org] On\n> Behalf Of Junio C Hamano\n> Sent: Thursday, May 11, 2017 4:16 AM\n> To: Jean-Noel Avila \n> Cc: git@vger.kernel.org; rashmipai36@gmail.com\n> Subject: Re: [PATCH v2 1/3] usability: don't ask questions if no reply is\n> required\n>\n> Jean-Noel Avila writes:\n>\n> > diff --git a/builtin/am.c b/builtin/am.c index a95dd8b4e..f5afa438d\n> > 100644\n> > --- a/builtin/am.c\n> > +++ b/builtin/am.c\n> > @@ -1312,7 +1312,7 @@ static int parse_mail(struct am_state *state, const\n> char *mail)\n> > }\n> >\n> > if (is_empty_file(am_path(state, \"patch\"))) {\n> > - printf_ln(_(\"Patch is empty. Was it split wrong?\"));\n> > + printf_ln(_(\"Patch is empty. It may have been split wrong.\"));\n> > die_user_resolve(state);\n> > }\n>\n> While I do not belong to \"we should feel free to ask rhetorical questions\"\n> camp, I do not mind this particular rewrite. An obvious alternative is just to\n> stop the sentence with \"Patch is empty.\"\n>\n> At this point in the code, we do not even know why we are seeing an empty\n> patch, and \"perhaps it was incorrectly split\" is not a particularly useful idle\n> speculation that would help the user who sees it.\n\ns/split wrong/split wrongly/\nThough the further discussion suggests that part of the phrase might best be removed entirely.\n\n\n> > @@ -1940,7 +1940,7 @@ static void am_resolve(struct am_state *state)\n> >\n> > if (unmerged_cache()) {\n> > printf_ln(_(\"You still have unmerged paths in your index.\\n\"\n> > - \"Did you forget to use 'git add'?\"));\n> > + \"You might want to use 'git add' on them.\"));\n>\n> This case is *not* an \"rhetorical question is the most succinct way to convey\n> the information\" situation; I think this rewrite is a definite improvement.\n> \"You might want to 'git add' them\" may be more succinct, though.\n\n\"You might want to use 'git add' on them.\"\nIt isn't about what you *want* to use, it's what you *need* to use, isn't it? And I'm not happy about \"on them\". I'm not sure quite why, but the phrasing seems odd.\nHow about \"You might need to use 'git add'.\", or \"You might need to use 'git add' first.\", or \"'git add' needs to be used to add files.\" , or \"'git add' needs to be used before any other git command may be used.\".\n\n\n> > diff --git a/builtin/checkout.c b/builtin/checkout.c index\n> > bfa5419f3..05037b9b6 100644\n> > --- a/builtin/checkout.c\n> > +++ b/builtin/checkout.c\n> > @@ -1287,7 +1287,7 @@ int cmd_checkout(int argc, const char **argv,\n> const char *prefix)\n> > */\n> > if (opts.new_branch && argc == 1)\n> > die(_(\"Cannot update paths and switch to branch '%s'\n> at the same time.\\n\"\n> > - \"Did you intend to checkout '%s' which can not be\n> resolved as commit?\"),\n> > + \"'%s' can not be resolved as commit, but it\n> should.\"),\n\n> I am not sure a firm statement \"but it should\" is an improvement.\n> This message is given when the user says:\n>\n> $ git checkout -b newone naster\n>\n> And \"but it should\" is appropriate when it is a mistyped \"I want to create and\n> checkout 'newone' branch at the same commit as 'master'\n> branch\", i.e.\n>\n> $ git checkout -b newone master\n>\n> The reason why the message begins with \"Cannot update paths and ...\"\n> is because it could be a mistyped \"I want to grab the file 'naster'\n> out of 'newone' branch\", i.e. the user meant to say this:\n>\n> $ git checkout newone naster\n>\n> IOW, the current error message is hedging its bets, because it does not want\n> to exclude the possibility that \"-b\" is there by mistake (as opposed to 'naster'\n> is the typo).\n>\n> If we ignore that possibility and assume that 'naster' is the typo (iow, the\n> user did mean \"-b\"), then your updated message makes sense. But if we\n> commit to \"the user meant -b\", we could make the message even more\n> helpful by being more direct, e.g.\n>\n> die(\"'%s' is not a commit and a branch '%s' cannot be created from\n> it\",\n> argv[0], opts.new_branch);\n\n\"'%s' can not be resolved as commit, but it should.\"\nIt should what ? Be resolved, or commit? Or something else?\nThe further comments above suggest that it might even be just \"'%s' can not be resolved.\"\n\n\n> > diff --git a/help.c b/help.c\n> > index bc6cd19cf..4658a55c6 100644\n> > --- a/help.c\n> > +++ b/help.c\n> > @@ -411,8 +411,8 @@ const char *help_unknown_cmd(const char *cmd)\n> >\n> > if (SIMILAR_ENOUGH(best_similarity)) {\n> > fprintf_ln(stderr,\n> > - Q_(\"\\nDid you mean this?\",\n> > - \"\\nDid you mean one of these?\",\n> > + Q_(\"\\nThe most approaching command is\",\n> > + \"\\nThe most approaching commands are\",\n> > n));\n>\n> With \"closest\" or \"most similar\", as others pointed out, I think this may be an\n> improvement.\n>\n> Thanks.\n\nRichard Kerry\nBNCS Engineer, SI SOL Telco & Media Vertical Practice\n\nT: +44 (0)20 3618 2669\nM: +44 (0)7812 325518\nLync: +44 (0) 20 3618 0778\nRoom G300, Stadium House, Wood Lane, London, W12 7TA\nrichard.kerry@atos.net\n\n\nAtos, Atos Consulting, Worldline and Canopy The Open Cloud Company are trading names used by the Atos group. The following trading entities are registered in England and Wales: Atos IT Services UK Limited (registered number 01245534), Atos Consulting Limited (registered number 04312380), Atos Worldline UK Limited (registered number 08514184) and Canopy The Open Cloud Company Limited (registration number 08011902). The registered office for each is at 4 Triton Square, Regent’s Place, London, NW1 3HG.The VAT No. for each is: GB232327983.\n\nThis e-mail and the documents attached are confidential and intended solely for the addressee, and may contain confidential or privileged information. If you receive this e-mail in error, you are not authorised to copy, disclose, use or retain it. Please notify the sender immediately and delete this email from your systems. As emails may be intercepted, amended or lost, they are not secure. Atos therefore can accept no liability for any errors or their content. Although Atos endeavours to maintain a virus-free network, we do not warrant that this transmission is virus-free and can accept no liability for any damages resulting from any virus transmitted. The risks are deemed to be accepted by everyone who communicates with Atos by email.\n"},{"id":"319386","messageId":"20170511102812.3ed3sqycjmapfj35@tigra","threadId":"45861","inReplyTo":"61C67DC73308BD49B2D4B65072480DBA2BDAB97D@DEERLM99EZ1MSX.ww931.my-it-solutions.net","subject":"Re: [PATCH v2 1/3] usability: don't ask questions if no reply is required","fromName":"Konstantin Khomoutov","fromEmail":"kostix+git@007spb.ru","sentAt":"2017-05-11T10:28:12Z","receivedAt":"2017-05-11T10:28:20Z","isPatch":true,"sender":{"key":"kostix+git@007spb.ru","avatar":null},"body":"On Thu, May 11, 2017 at 10:10:05AM +0000, Kerry, Richard wrote:\n\n[...]\n> > > @@ -1940,7 +1940,7 @@ static void am_resolve(struct am_state *state)\n> > >\n> > > if (unmerged_cache()) {\n> > > printf_ln(_(\"You still have unmerged paths in your index.\\n\"\n> > > - \"Did you forget to use 'git add'?\"));\n> > > + \"You might want to use 'git add' on them.\"));\n> >\n> > This case is *not* an \"rhetorical question is the most succinct way to convey\n> > the information\" situation; I think this rewrite is a definite improvement.\n> > \"You might want to 'git add' them\" may be more succinct, though.\n> \n> \"You might want to use 'git add' on them.\" It isn't about what you\n> *want* to use, it's what you *need* to use, isn't it? And I'm not\n> happy about \"on them\". I'm not sure quite why, but the phrasing seems\n> odd. How about \"You might need to use 'git add'.\", or \"You might need\n> to use 'git add' first.\", or \"'git add' needs to be used to add\n> files.\" , or \"'git add' needs to be used before any other git command\n> may be used.\".\n\nWhy not just\n\n You should run `git add` on each file with resolved conflicts to mark\n them as such.\n\nI'm not an English speaker but IMHO this phrasing concentrates on the\nessense of the problem. It's far from being succint, unfortunately.\n\nI also wonder what to do with \"deleted by them\" state of certain files\nwhich are also \"unmerged\" but `git add`-ing them would be a wrong thing\nto do if we want to accept the upstream's decision to delete the file.\nSo maybe something like\n\n You might run `git rm` on a file to accept \"deleted by them\" for it.\n\nappended to the original hint would be good.\n\n"},{"id":"319387","messageId":"CACBZZX7YV2Xx43vn50x1ZO70=et9kNBrCKKoR8xRo1NCQPR2gw@mail.gmail.com","threadId":"45861","inReplyTo":"20170511102812.3ed3sqycjmapfj35@tigra","subject":"Re: [PATCH v2 1/3] usability: don't ask questions if no reply is required","fromName":"Ævar Arnfjörð Bjarmason","fromEmail":"avarab@gmail.com","sentAt":"2017-05-11T10:33:18Z","receivedAt":"2017-05-11T10:33:46Z","isPatch":true,"sender":{"key":"avarab@gmail.com","avatar":"https://avatars.githubusercontent.com/u/45301?v=4"},"body":"On Thu, May 11, 2017 at 12:28 PM, Konstantin Khomoutov\n wrote:\n> On Thu, May 11, 2017 at 10:10:05AM +0000, Kerry, Richard wrote:\n>\n> [...]\n>> > > @@ -1940,7 +1940,7 @@ static void am_resolve(struct am_state *state)\n>> > >\n>> > > if (unmerged_cache()) {\n>> > > printf_ln(_(\"You still have unmerged paths in your index.\\n\"\n>> > > - \"Did you forget to use 'git add'?\"));\n>> > > + \"You might want to use 'git add' on them.\"));\n>> >\n>> > This case is *not* an \"rhetorical question is the most succinct way to convey\n>> > the information\" situation; I think this rewrite is a definite improvement.\n>> > \"You might want to 'git add' them\" may be more succinct, though.\n>>\n>> \"You might want to use 'git add' on them.\" It isn't about what you\n>> *want* to use, it's what you *need* to use, isn't it? And I'm not\n>> happy about \"on them\". I'm not sure quite why, but the phrasing seems\n>> odd. How about \"You might need to use 'git add'.\", or \"You might need\n>> to use 'git add' first.\", or \"'git add' needs to be used to add\n>> files.\" , or \"'git add' needs to be used before any other git command\n>> may be used.\".\n>\n> Why not just\n>\n> You should run `git add` on each file with resolved conflicts to mark\n> them as such.\n>\n> I'm not an English speaker but IMHO this phrasing concentrates on the\n> essense of the problem. It's far from being succint, unfortunately.\n>\n> I also wonder what to do with \"deleted by them\" state of certain files\n> which are also \"unmerged\" but `git add`-ing them would be a wrong thing\n> to do if we want to accept the upstream's decision to delete the file.\n> So maybe something like\n>\n> You might run `git rm` on a file to accept \"deleted by them\" for it.\n>\n> appended to the original hint would be good.\n\nI think something like this sounds much better. I think being a bit\nmore verbose is good here, if you know how to solve conflicts you just\ngo \"oops, forgot\", but for confused users who don't know how, it's\nbetter to explain things a bit more verbosely.\n"},{"id":"319389","messageId":"20170511120634.17683-1-jn.avila@free.fr","threadId":"45861","inReplyTo":"20170503162931.30721-1-jn.avila@free.fr","subject":"[PATCH v3 1/3] usability: don't ask questions if no reply is required","fromName":"Jean-Noel Avila","fromEmail":"jn.avila@free.fr","sentAt":"2017-05-11T12:06:32Z","receivedAt":"2017-05-11T12:06:50Z","isPatch":true,"sender":{"key":"jn.avila@free.fr","avatar":"https://avatars.githubusercontent.com/u/156172?v=4"},"body":"There has been a bug report by a corporate user that stated that\n\"spelling mistake of stash followed by a yes prints character 'y'\ninfinite times.\"\n\nThis analysis was false. When the spelling of a command contains\nerrors, the git program tries to help the user by providing candidates\nwhich are close to the unexisting command. E.g Git prints the\nfollowing:\n\n git: 'stahs' is not a git command. See 'git --help'.\n Did you mean this?\n\n stash\n\nand then exits.\n\nThe problem with this hint is that it is not formally indicated as an\nhint and the user is in fact encouraged to reply to the question,\nwhereas the Git command is already finished.\n\nThe user was unlucky enough that it was the command he was looking\nfor, and replied \"yes\" on the command line, effectively launching the\n`yes` program.\n\nThe initial error is that the Git programs, when launched in\ncommand-line mode (without interaction) must not ask questions,\nbecause these questions would normally require a user input as a reply\nthat they won't handle indeed. That's a source of confusion on UX\nlevel.\n\nTo improve the general usability of the Git suite, the following rule\nwas applied:\n\nif the sentence\n * appears in a non-interactive session\n * is printed last before exit\n * is a question addressing the user (\"you\")\n\nthe sentence is turned into affirmative and proposes the option.\n\nThe basic rewording of the question sentences has been extended to\nother spots found in the source.\n\nRequested at https://github.com/git/git-scm.com/issues/999 by rpai1\n\nSigned-off-by: Jean-Noel Avila \n---\n builtin/am.c | 5 +++--\n builtin/checkout.c | 5 ++---\n help.c | 4 ++--\n 3 files changed, 7 insertions(+), 7 deletions(-)\n\ndiff --git a/builtin/am.c b/builtin/am.c\nindex a95dd8b4e..dd60fad1e 100644\n--- a/builtin/am.c\n+++ b/builtin/am.c\n@@ -1312,7 +1312,7 @@ static int parse_mail(struct am_state *state, const char *mail)\n \t}\n \n \tif (is_empty_file(am_path(state, \"patch\"))) {\n-\t\tprintf_ln(_(\"Patch is empty. Was it split wrong?\"));\n+\t\tprintf_ln(_(\"Patch is empty.\"));\n \t\tdie_user_resolve(state);\n \t}\n \n@@ -1940,7 +1940,8 @@ static void am_resolve(struct am_state *state)\n \n \tif (unmerged_cache()) {\n \t\tprintf_ln(_(\"You still have unmerged paths in your index.\\n\"\n-\t\t\t\"Did you forget to use 'git add'?\"));\n+\t\t\t\"You should 'git add' each file with resolved conflicts to mark them as such.\\n\"\n+\t\t\t\"You might run `git rm` on a file to accept \\\"deleted by them\\\" for it.\"));\n \t\tdie_user_resolve(state);\n \t}\n \ndiff --git a/builtin/checkout.c b/builtin/checkout.c\nindex bfa5419f3..85c04d252 100644\n--- a/builtin/checkout.c\n+++ b/builtin/checkout.c\n@@ -1286,9 +1286,8 @@ int cmd_checkout(int argc, const char **argv, const char *prefix)\n \t\t * new_branch && argc > 1 will be caught later.\n \t\t */\n \t\tif (opts.new_branch && argc == 1)\n-\t\t\tdie(_(\"Cannot update paths and switch to branch '%s' at the same time.\\n\"\n-\t\t\t \"Did you intend to checkout '%s' which can not be resolved as commit?\"),\n-\t\t\t opts.new_branch, argv[0]);\n+\t\t\tdie(_(\"'%s' is not a commit and a branch '%s' cannot be created from it\"),\n+\t\t\t\targv[0], opts.new_branch);\n \n \t\tif (opts.force_detach)\n \t\t\tdie(_(\"git checkout: --detach does not take a path argument '%s'\"),\ndiff --git a/help.c b/help.c\nindex bc6cd19cf..a07f01e6f 100644\n--- a/help.c\n+++ b/help.c\n@@ -411,8 +411,8 @@ const char *help_unknown_cmd(const char *cmd)\n \n \tif (SIMILAR_ENOUGH(best_similarity)) {\n \t\tfprintf_ln(stderr,\n-\t\t\t Q_(\"\\nDid you mean this?\",\n-\t\t\t \"\\nDid you mean one of these?\",\n+\t\t\t Q_(\"\\nThe most similar command is\",\n+\t\t\t \"\\nThe most similar commands are\",\n \t\t\t n));\n \n \t\tfor (i = 0; i < n; i++)\n-- \n2.13.0\n\n"},{"id":"319390","messageId":"20170511120634.17683-2-jn.avila@free.fr","threadId":"45861","inReplyTo":"20170511120634.17683-1-jn.avila@free.fr","subject":"[PATCH v3 2/3] read-tree -m: make error message for merging 0 trees less smart aleck","fromName":"Jean-Noel Avila","fromEmail":"jn.avila@free.fr","sentAt":"2017-05-11T12:06:33Z","receivedAt":"2017-05-11T12:06:51Z","isPatch":true,"sender":{"key":"jn.avila@free.fr","avatar":"https://avatars.githubusercontent.com/u/156172?v=4"},"body":"\"git read-tree -m\" requires a tree argument to name the tree to be\nmerged in. Git uses a cutesy error message to say so and why:\n\n $ git read-tree -m\n warning: read-tree: emptying the index with no arguments is\n deprecated; use --empty\n fatal: just how do you expect me to merge 0 trees?\n $ git read-tree -m --empty\n fatal: just how do you expect me to merge 0 trees?\n\nWhen lucky, that could produce an ah-hah moment for the user, but it's\nmore likely to irritate and distract them.\n\nInstead, tell the user plainly that the tree argument is\nrequired. Also document this requirement in the git-read-tree(1)\nmanpage where there is room to explain it in a more straightforward way.\n\nSigned-off-by: Jean-Noel Avila \nSigned-off-by: Jonathan Nieder \n---\n Documentation/git-read-tree.txt | 8 ++++----\n builtin/read-tree.c | 7 ++++---\n 2 files changed, 8 insertions(+), 7 deletions(-)\n\ndiff --git a/Documentation/git-read-tree.txt b/Documentation/git-read-tree.txt\nindex ed9d63ef4..97df00043 100644\n--- a/Documentation/git-read-tree.txt\n+++ b/Documentation/git-read-tree.txt\n@@ -135,10 +135,10 @@ OPTIONS\n \n Merging\n -------\n-If `-m` is specified, 'git read-tree' can perform 3 kinds of\n-merge, a single tree merge if only 1 tree is given, a\n-fast-forward merge with 2 trees, or a 3-way merge if 3 trees are\n-provided.\n+If `-m` is specified, at least one tree must be given on the command\n+line. 'git read-tree' can perform 3 kinds of merge, a single tree\n+merge if only 1 tree is given, a fast-forward merge with 2 trees, or a\n+3-way merge if 3 or more trees are provided.\n \n \n Single Tree Merge\ndiff --git a/builtin/read-tree.c b/builtin/read-tree.c\nindex 23e212ee8..de1a58d17 100644\n--- a/builtin/read-tree.c\n+++ b/builtin/read-tree.c\n@@ -132,7 +132,7 @@ int cmd_read_tree(int argc, const char **argv, const char *unused_prefix)\n \t\tOPT_BOOL(0, \"empty\", &read_empty,\n \t\t\t N_(\"only empty the index\")),\n \t\tOPT__VERBOSE(&opts.verbose_update, N_(\"be verbose\")),\n-\t\tOPT_GROUP(N_(\"Merging\")),\n+\t\tOPT_GROUP(N_(\"Merging (needs at least one tree-ish\")),\n \t\tOPT_BOOL('m', NULL, &opts.merge,\n \t\t\t N_(\"perform a merge in addition to a read\")),\n \t\tOPT_BOOL(0, \"trivial\", &opts.trivial_merges_only,\n@@ -226,9 +226,10 @@ int cmd_read_tree(int argc, const char **argv, const char *unused_prefix)\n \t\tsetup_work_tree();\n \n \tif (opts.merge) {\n-\t\tif (stage < 2)\n-\t\t\tdie(\"just how do you expect me to merge %d trees?\", stage-1);\n \t\tswitch (stage - 1) {\n+\t\tcase 0:\n+\t\t\tdie(_(\"you must specify at least one tree to merge\"));\n+\t\t\tbreak;\n \t\tcase 1:\n \t\t\topts.fn = opts.prefix ? bind_merge : oneway_merge;\n \t\t\tbreak;\n-- \n2.13.0\n\n"},{"id":"319391","messageId":"20170511120634.17683-3-jn.avila@free.fr","threadId":"45861","inReplyTo":"20170511120634.17683-1-jn.avila@free.fr","subject":"[PATCH v3 3/3] git-filter-branch:","fromName":"Jean-Noel Avila","fromEmail":"jn.avila@free.fr","sentAt":"2017-05-11T12:06:34Z","receivedAt":"2017-05-11T12:06:54Z","isPatch":true,"sender":{"key":"jn.avila@free.fr","avatar":"https://avatars.githubusercontent.com/u/156172?v=4"},"body":"git-filter-branch requires the specification of a branch by one way or\nanother. If no branch appears to have been specified, we know the user\ngot the usage wrong but we don't know what they were trying to do ---\ne.g. maybe they specified the ref to rewrite but in the wrong place.\n\nIn this case, just state that the branch specification is missing.\n\nSigned-off-by: Jean-Noel Avila \n---\n git-filter-branch.sh | 2 +-\n 1 file changed, 1 insertion(+), 1 deletion(-)\n\ndiff --git a/git-filter-branch.sh b/git-filter-branch.sh\nindex 2b8cdba15..aafaf708d 100755\n--- a/git-filter-branch.sh\n+++ b/git-filter-branch.sh\n@@ -239,7 +239,7 @@ git rev-parse --no-flags --revs-only --symbolic-full-name \\\n sed -e '/^^/d' \"$tempdir\"/raw-heads >\"$tempdir\"/heads\n \n test -s \"$tempdir\"/heads ||\n-\tdie \"Which ref do you want to rewrite?\"\n+\tdie \"You must specify a ref to rewrite.\"\n \n GIT_INDEX_FILE=\"$(pwd)/../index\"\n export GIT_INDEX_FILE\n-- \n2.13.0\n\n"},{"id":"319440","messageId":"20170511190809.GB12516@aiede.svl.corp.google.com","threadId":"45861","inReplyTo":"20170511120634.17683-2-jn.avila@free.fr","subject":"Re: [PATCH v3 2/3] read-tree -m: make error message for merging 0 trees less smart aleck","fromName":"Jonathan Nieder","fromEmail":"jrnieder@gmail.com","sentAt":"2017-05-11T19:08:09Z","receivedAt":"2017-05-11T19:08:16Z","isPatch":true,"sender":{"key":"jrnieder@gmail.com","avatar":"https://avatars.githubusercontent.com/u/281595?v=4"},"body":"Hi,\n\nJean-Noel Avila wrote:\n\n> Signed-off-by: Jean-Noel Avila \n> Signed-off-by: Jonathan Nieder \n\nPlease remove my sign-off. I didn't write or carry this patch.\n\nIf you want to acknowledge my contribution, you can use something\nlike Helped-by, but it's not necessary.\n\n[...]\n> +++ b/Documentation/git-read-tree.txt\n> @@ -135,10 +135,10 @@ OPTIONS\n> \n> Merging\n> -------\n> -If `-m` is specified, 'git read-tree' can perform 3 kinds of\n> -merge, a single tree merge if only 1 tree is given, a\n> -fast-forward merge with 2 trees, or a 3-way merge if 3 trees are\n> -provided.\n> +If `-m` is specified, at least one tree must be given on the command\n> +line.\n\nAs I mentioned before, this sentence feels redundant and doesn't fix\nthe real problem of the `-m` reference elsewhere in this file not\npointing to this section.\n\n[...]\n> --- a/builtin/read-tree.c\n> +++ b/builtin/read-tree.c\n> @@ -132,7 +132,7 @@ int cmd_read_tree(int argc, const char **argv, const char *unused_prefix)\n> \t\tOPT_BOOL(0, \"empty\", &read_empty,\n> \t\t\t N_(\"only empty the index\")),\n> \t\tOPT__VERBOSE(&opts.verbose_update, N_(\"be verbose\")),\n> -\t\tOPT_GROUP(N_(\"Merging\")),\n> +\t\tOPT_GROUP(N_(\"Merging (needs at least one tree-ish\")),\n\nThis also seems a little too much of a special detail to put in the\nprominent section title. If you run \"git read-tree -h\", where would\nyou expect to find this information?\n\nThe \"git read-tree -h\" output turns out to not be useful for much more\nthan a reminder of supported options --- it doesn't give a useful\noverview of the usage, since the usage string at the start is very\nlong. That's unfortunate but it seems outside the scope of this\npatch. Probably the simplest thing is to drop this hunk from the\npatch.\n\n\n[...]\n> @@ -226,9 +226,10 @@ int cmd_read_tree(int argc, const char **argv, const char *unused_prefix)\n> \t\tsetup_work_tree();\n> \n> \tif (opts.merge) {\n> -\t\tif (stage < 2)\n> -\t\t\tdie(\"just how do you expect me to merge %d trees?\", stage-1);\n> \t\tswitch (stage - 1) {\n> +\t\tcase 0:\n> +\t\t\tdie(_(\"you must specify at least one tree to merge\"));\n> +\t\t\tbreak;\n\nThis part looks good.\n\nThanks for your patient work.\nJonathan\n"},{"id":"319504","messageId":"3385764.ta7K6ELq6T@cayenne","threadId":"45861","inReplyTo":"xmqqtw4q6122.fsf@gitster.mtv.corp.google.com","subject":"Re: [PATCH v3 2/3] read-tree -m: make error message for merging 0 trees less smart aleck","fromName":"Jean-Noël AVILA","fromEmail":"jn.avila@free.fr","sentAt":"2017-05-12T12:54:50Z","receivedAt":"2017-05-12T18:44:39Z","isPatch":true,"sender":{"key":"jn.avila@free.fr","avatar":"https://avatars.githubusercontent.com/u/156172?v=4"},"body":"On Friday, 12 May 2017, 15:28:53 CEST Junio C Hamano wrote:\n> Jonathan Nieder writes:\n> \n> >> @@ -226,9 +226,10 @@ int cmd_read_tree(int argc, const char **argv, const char *unused_prefix)\n> >> \t\tsetup_work_tree();\n> >> \n> >> \tif (opts.merge) {\n> >> -\t\tif (stage < 2)\n> >> -\t\t\tdie(\"just how do you expect me to merge %d trees?\", stage-1);\n> >> \t\tswitch (stage - 1) {\n> >> +\t\tcase 0:\n> >> +\t\t\tdie(_(\"you must specify at least one tree to merge\"));\n> >> +\t\t\tbreak;\n> >\n> > This part looks good.\n> \n> Thanks. Modulo _(\"\"); I do not think other messages from read-tree\n> are marked for i18n (yet).\n> \n\nThe documentation is already i18n, but not the dying messages. This can take place in a specific patch series.\n\nThanks. Will reroll. \n\n"},{"id":"319516","messageId":"xmqqtw4q6122.fsf@gitster.mtv.corp.google.com","threadId":"45861","inReplyTo":"20170511190809.GB12516@aiede.svl.corp.google.com","subject":"Re: [PATCH v3 2/3] read-tree -m: make error message for merging 0 trees less smart aleck","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2017-05-12T06:28:53Z","receivedAt":"2017-05-12T18:45:00Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Jonathan Nieder writes:\n\n>> @@ -226,9 +226,10 @@ int cmd_read_tree(int argc, const char **argv, const char *unused_prefix)\n>> \t\tsetup_work_tree();\n>> \n>> \tif (opts.merge) {\n>> -\t\tif (stage < 2)\n>> -\t\t\tdie(\"just how do you expect me to merge %d trees?\", stage-1);\n>> \t\tswitch (stage - 1) {\n>> +\t\tcase 0:\n>> +\t\t\tdie(_(\"you must specify at least one tree to merge\"));\n>> +\t\t\tbreak;\n>\n> This part looks good.\n\nThanks. Modulo _(\"\"); I do not think other messages from read-tree\nare marked for i18n (yet).\n"},{"id":"319527","messageId":"20170512130317.25832-2-jn.avila@free.fr","threadId":"45861","inReplyTo":"20170512130317.25832-1-jn.avila@free.fr","subject":"[PATCH v4 2/3] read-tree -m: make error message for merging 0 trees less smart aleck","fromName":"Jean-Noel Avila","fromEmail":"jn.avila@free.fr","sentAt":"2017-05-12T13:03:16Z","receivedAt":"2017-05-12T18:45:17Z","isPatch":true,"sender":{"key":"jn.avila@free.fr","avatar":"https://avatars.githubusercontent.com/u/156172?v=4"},"body":"\"git read-tree -m\" requires a tree argument to name the tree to be\nmerged in. Git uses a cutesy error message to say so and why:\n\n $ git read-tree -m\n warning: read-tree: emptying the index with no arguments is\n deprecated; use --empty\n fatal: just how do you expect me to merge 0 trees?\n $ git read-tree -m --empty\n fatal: just how do you expect me to merge 0 trees?\n\nWhen lucky, that could produce an ah-hah moment for the user, but it's\nmore likely to irritate and distract them.\n\nInstead, tell the user plainly that the tree argument is\nrequired. Also document that more than 3 trees can be merged.\n\nSigned-off-by: Jean-Noel Avila \n---\n Documentation/git-read-tree.txt | 7 +++----\n builtin/read-tree.c | 5 +++--\n 2 files changed, 6 insertions(+), 6 deletions(-)\n\ndiff --git a/Documentation/git-read-tree.txt b/Documentation/git-read-tree.txt\nindex ed9d63ef4..7e20b0c21 100644\n--- a/Documentation/git-read-tree.txt\n+++ b/Documentation/git-read-tree.txt\n@@ -135,10 +135,9 @@ OPTIONS\n \n Merging\n -------\n-If `-m` is specified, 'git read-tree' can perform 3 kinds of\n-merge, a single tree merge if only 1 tree is given, a\n-fast-forward merge with 2 trees, or a 3-way merge if 3 trees are\n-provided.\n+If `-m` is specified, 'git read-tree' can perform 3 kinds of merge, a\n+single tree merge if only 1 tree is given, a fast-forward merge with 2\n+trees, or a 3-way merge if 3 or more trees are provided.\n \n \n Single Tree Merge\ndiff --git a/builtin/read-tree.c b/builtin/read-tree.c\nindex 23e212ee8..383442567 100644\n--- a/builtin/read-tree.c\n+++ b/builtin/read-tree.c\n@@ -226,9 +226,10 @@ int cmd_read_tree(int argc, const char **argv, const char *unused_prefix)\n \t\tsetup_work_tree();\n \n \tif (opts.merge) {\n-\t\tif (stage < 2)\n-\t\t\tdie(\"just how do you expect me to merge %d trees?\", stage-1);\n \t\tswitch (stage - 1) {\n+\t\tcase 0:\n+\t\t\tdie(\"you must specify at least one tree to merge\");\n+\t\t\tbreak;\n \t\tcase 1:\n \t\t\topts.fn = opts.prefix ? bind_merge : oneway_merge;\n \t\t\tbreak;\n-- \n2.13.0\n\n"},{"id":"319543","messageId":"20170512130317.25832-1-jn.avila@free.fr","threadId":"45861","inReplyTo":"20170503162931.30721-1-jn.avila@free.fr","subject":"[PATCH v4 1/3] usability: don't ask questions if no reply is required","fromName":"Jean-Noel Avila","fromEmail":"jn.avila@free.fr","sentAt":"2017-05-12T13:03:15Z","receivedAt":"2017-05-12T18:45:44Z","isPatch":true,"sender":{"key":"jn.avila@free.fr","avatar":"https://avatars.githubusercontent.com/u/156172?v=4"},"body":"There has been a bug report by a corporate user that stated that\n\"spelling mistake of stash followed by a yes prints character 'y'\ninfinite times.\"\n\nThis analysis was false. When the spelling of a command contains\nerrors, the git program tries to help the user by providing candidates\nwhich are close to the unexisting command. E.g Git prints the\nfollowing:\n\n git: 'stahs' is not a git command. See 'git --help'.\n Did you mean this?\n\n stash\n\nand then exits.\n\nThe problem with this hint is that it is not formally indicated as an\nhint and the user is in fact encouraged to reply to the question,\nwhereas the Git command is already finished.\n\nThe user was unlucky enough that it was the command he was looking\nfor, and replied \"yes\" on the command line, effectively launching the\n`yes` program.\n\nThe initial error is that the Git programs, when launched in\ncommand-line mode (without interaction) must not ask questions,\nbecause these questions would normally require a user input as a reply\nthat they won't handle indeed. That's a source of confusion on UX\nlevel.\n\nTo improve the general usability of the Git suite, the following rule\nwas applied:\n\nif the sentence\n * appears in a non-interactive session\n * is printed last before exit\n * is a question addressing the user (\"you\")\n\nthe sentence is turned into affirmative and proposes the option.\n\nThe basic rewording of the question sentences has been extended to\nother spots found in the source.\n\nRequested at https://github.com/git/git-scm.com/issues/999 by rpai1\n\nSigned-off-by: Jean-Noel Avila \n---\n builtin/am.c | 5 +++--\n builtin/checkout.c | 5 ++---\n help.c | 4 ++--\n 3 files changed, 7 insertions(+), 7 deletions(-)\n\ndiff --git a/builtin/am.c b/builtin/am.c\nindex a95dd8b4e..dd60fad1e 100644\n--- a/builtin/am.c\n+++ b/builtin/am.c\n@@ -1312,7 +1312,7 @@ static int parse_mail(struct am_state *state, const char *mail)\n \t}\n \n \tif (is_empty_file(am_path(state, \"patch\"))) {\n-\t\tprintf_ln(_(\"Patch is empty. Was it split wrong?\"));\n+\t\tprintf_ln(_(\"Patch is empty.\"));\n \t\tdie_user_resolve(state);\n \t}\n \n@@ -1940,7 +1940,8 @@ static void am_resolve(struct am_state *state)\n \n \tif (unmerged_cache()) {\n \t\tprintf_ln(_(\"You still have unmerged paths in your index.\\n\"\n-\t\t\t\"Did you forget to use 'git add'?\"));\n+\t\t\t\"You should 'git add' each file with resolved conflicts to mark them as such.\\n\"\n+\t\t\t\"You might run `git rm` on a file to accept \\\"deleted by them\\\" for it.\"));\n \t\tdie_user_resolve(state);\n \t}\n \ndiff --git a/builtin/checkout.c b/builtin/checkout.c\nindex bfa5419f3..85c04d252 100644\n--- a/builtin/checkout.c\n+++ b/builtin/checkout.c\n@@ -1286,9 +1286,8 @@ int cmd_checkout(int argc, const char **argv, const char *prefix)\n \t\t * new_branch && argc > 1 will be caught later.\n \t\t */\n \t\tif (opts.new_branch && argc == 1)\n-\t\t\tdie(_(\"Cannot update paths and switch to branch '%s' at the same time.\\n\"\n-\t\t\t \"Did you intend to checkout '%s' which can not be resolved as commit?\"),\n-\t\t\t opts.new_branch, argv[0]);\n+\t\t\tdie(_(\"'%s' is not a commit and a branch '%s' cannot be created from it\"),\n+\t\t\t\targv[0], opts.new_branch);\n \n \t\tif (opts.force_detach)\n \t\t\tdie(_(\"git checkout: --detach does not take a path argument '%s'\"),\ndiff --git a/help.c b/help.c\nindex bc6cd19cf..a07f01e6f 100644\n--- a/help.c\n+++ b/help.c\n@@ -411,8 +411,8 @@ const char *help_unknown_cmd(const char *cmd)\n \n \tif (SIMILAR_ENOUGH(best_similarity)) {\n \t\tfprintf_ln(stderr,\n-\t\t\t Q_(\"\\nDid you mean this?\",\n-\t\t\t \"\\nDid you mean one of these?\",\n+\t\t\t Q_(\"\\nThe most similar command is\",\n+\t\t\t \"\\nThe most similar commands are\",\n \t\t\t n));\n \n \t\tfor (i = 0; i < n; i++)\n-- \n2.13.0\n\n"},{"id":"319546","messageId":"xmqqy3u26153.fsf@gitster.mtv.corp.google.com","threadId":"45861","inReplyTo":"20170511120634.17683-3-jn.avila@free.fr","subject":"Re: [PATCH v3 3/3] git-filter-branch:","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2017-05-12T06:27:04Z","receivedAt":"2017-05-12T18:45:52Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Jean-Noel Avila writes:\n\n> Subject: Re: [PATCH v3 3/3] git-filter-branch:\n\nForgot the body of the single-liner summary? In the meantime I'll\nqueue this as:\n\n\tSubject: git-filter-branch: be more direct in an error message\n\n> test -s \"$tempdir\"/heads ||\n> -\tdie \"Which ref do you want to rewrite?\"\n> +\tdie \"You must specify a ref to rewrite.\"\n\nSounds OK, even though this (both the old and the new phrasing)\nmakes me wonder if the program can rewrite only one ref, or it can\naccept more than one.\n\nThanks.\n"},{"id":"319557","messageId":"20170512130317.25832-3-jn.avila@free.fr","threadId":"45861","inReplyTo":"20170512130317.25832-1-jn.avila@free.fr","subject":"[PATCH v4 3/3] git-filter-branch: be more direct in an error message","fromName":"Jean-Noel Avila","fromEmail":"jn.avila@free.fr","sentAt":"2017-05-12T13:03:17Z","receivedAt":"2017-05-12T18:46:14Z","isPatch":true,"sender":{"key":"jn.avila@free.fr","avatar":"https://avatars.githubusercontent.com/u/156172?v=4"},"body":"git-filter-branch requires the specification of a branch by one way or\nanother. If no branch appears to have been specified, we know the user\ngot the usage wrong but we don't know what they were trying to do ---\ne.g. maybe they specified the ref to rewrite but in the wrong place.\n\nIn this case, just state that the branch specification is missing.\n\nSigned-off-by: Jean-Noel Avila \n---\n git-filter-branch.sh | 2 +-\n 1 file changed, 1 insertion(+), 1 deletion(-)\n\ndiff --git a/git-filter-branch.sh b/git-filter-branch.sh\nindex 2b8cdba15..aafaf708d 100755\n--- a/git-filter-branch.sh\n+++ b/git-filter-branch.sh\n@@ -239,7 +239,7 @@ git rev-parse --no-flags --revs-only --symbolic-full-name \\\n sed -e '/^^/d' \"$tempdir\"/raw-heads >\"$tempdir\"/heads\n \n test -s \"$tempdir\"/heads ||\n-\tdie \"Which ref do you want to rewrite?\"\n+\tdie \"You must specify a ref to rewrite.\"\n \n GIT_INDEX_FILE=\"$(pwd)/../index\"\n export GIT_INDEX_FILE\n-- \n2.13.0\n\n"},{"id":"319580","messageId":"xmqqpofd4s91.fsf@gitster.mtv.corp.google.com","threadId":"45861","inReplyTo":"20170512130317.25832-1-jn.avila@free.fr","subject":"Re: [PATCH v4 1/3] usability: don't ask questions if no reply is required","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2017-05-12T22:36:42Z","receivedAt":"2017-05-12T22:36:48Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Thanks, all three patches look good. Will queue.\n\nLet's merge them to 'next' soonish and eventually down to 'master'\nand 'maint'.\n\nThanks.\n"},{"id":"319618","messageId":"3c1fb7c7-9306-b0c9-f0ea-cabcd944b124@kdbg.org","threadId":"45861","inReplyTo":"xmqqpofd4s91.fsf@gitster.mtv.corp.google.com","subject":"Re: [PATCH v4 1/3] usability: don't ask questions if no reply is required","fromName":"Johannes Sixt","fromEmail":"j6t@kdbg.org","sentAt":"2017-05-13T15:37:25Z","receivedAt":"2017-05-13T15:37:33Z","isPatch":true,"sender":{"key":"j6t@kdbg.org","avatar":"https://avatars.githubusercontent.com/u/14810926?v=4"},"body":"Am 13.05.2017 um 00:36 schrieb Junio C Hamano:\n> Thanks, all three patches look good. Will queue.\n> \n> Let's merge them to 'next' soonish and eventually down to 'master'\n> and 'maint'.\n\nThe patches change translated strings. You should probably wait for an \nupdate of their translations before you release a maintenance version \nwith these changes.\n\n-- Hannes\n"},{"id":"319741","messageId":"xmqq7f1iyi9r.fsf@gitster.mtv.corp.google.com","threadId":"45861","inReplyTo":"3c1fb7c7-9306-b0c9-f0ea-cabcd944b124@kdbg.org","subject":"Re: [PATCH v4 1/3] usability: don't ask questions if no reply is required","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2017-05-15T02:18:40Z","receivedAt":"2017-05-15T02:18:50Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Johannes Sixt writes:\n\n> Am 13.05.2017 um 00:36 schrieb Junio C Hamano:\n>> Thanks, all three patches look good. Will queue.\n>>\n>> Let's merge them to 'next' soonish and eventually down to 'master'\n>> and 'maint'.\n>\n> The patches change translated strings. You should probably wait for an\n> update of their translations before you release a maintenance version\n> with these changes.\n\nYup, thanks.\n"}]}