On Thu, May 4, 2017 at 10:52 AM, Kerry, Richard <richard.ke...@atos.net> wrote: > > May I suggest that " The most approaching commands" doesn't make much sense > as English (I don't think a command can "approach"). > Perhaps it should be " The most appropriate commands".
I had the same concern, saying "appropriate" is IMO also confusing. The point of this UI is not to point out what you should be running, which "appropriate" implies, but just "we couldn't find what you meant, did you mean one of these?". I think nothing needs to change here. The whole premise here is that a program should never ask a question when you can't give an answer, I think that's nonsense. There's such a thing as a rhetorical question, and sometimes using that form is the most obvious & succinct way to put things. Which is not to say that phrasing these things as a non-question can't be better, but the suggestions so far just seem more complex. Also keep in mind that a huge part of the user base for git using the English UI consists of non-native speakers, and when in doubt we should definitely be picking simpler English like "did you mean?" v.s. alternatives with >10 character more obscure words. > Richard Kerry > BNCS Engineer, SI SOL Telco & Media Vertical Practice > > T: +44 (0)20 3618 2669 > M: +44 (0)7812 325518 > Lync: +44 (0) 20 3618 0778 > Room G300, Stadium House, Wood Lane, London, W12 7TA > richard.ke...@atos.net > > > > > -----Original Message----- > From: git-ow...@vger.kernel.org [mailto:git-ow...@vger.kernel.org] On Behalf > Of Jean-Noel Avila > Sent: Wednesday, May 03, 2017 10:07 PM > To: git@vger.kernel.org > Cc: rashmipa...@gmail.com; Jean-Noel Avila <jn.av...@free.fr> > Subject: [PATCH v2 1/3] usability: don't ask questions if no reply is required > > There has been a bug report by a corporate user that stated that "spelling > mistake of stash followed by a yes prints character 'y' > infinite times." > > 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 > following: > > git: 'stahs' is not a git command. See 'git --help'. > Did you mean this? > > stash > > and then exits. > > 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. > > 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. > > 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. > > To improve the general usability of the Git suite, the following rule was > applied: > > if the sentence > * appears in a non-interactive session > * is printed last before exit > * is a question addressing the user ("you") > > the sentence is turned into affirmative and proposes the option. > > The basic rewording of the question sentences has been extended to other > spots found in the source. > > Requested at https://github.com/git/git-scm.com/issues/999 by rpai1 > > Signed-off-by: Jean-Noel Avila <jn.av...@free.fr> > --- > builtin/am.c | 4 ++-- > builtin/checkout.c | 2 +- > help.c | 4 ++-- > 3 files changed, 5 insertions(+), 5 deletions(-) > > diff --git a/builtin/am.c b/builtin/am.c index a95dd8b4e..f5afa438d 100644 > --- a/builtin/am.c > +++ b/builtin/am.c > @@ -1312,7 +1312,7 @@ static int parse_mail(struct am_state *state, const > char *mail) > } > > if (is_empty_file(am_path(state, "patch"))) { > - printf_ln(_("Patch is empty. Was it split wrong?")); > + printf_ln(_("Patch is empty. It may have been split wrong.")); > die_user_resolve(state); > } > > @@ -1940,7 +1940,7 @@ static void am_resolve(struct am_state *state) > > if (unmerged_cache()) { > printf_ln(_("You still have unmerged paths in your index.\n" > - "Did you forget to use 'git add'?")); > + "You might want to use 'git add' on them.")); > die_user_resolve(state); > } > > diff --git a/builtin/checkout.c b/builtin/checkout.c index > bfa5419f3..05037b9b6 100644 > --- a/builtin/checkout.c > +++ b/builtin/checkout.c > @@ -1287,7 +1287,7 @@ int cmd_checkout(int argc, const char **argv, const > char *prefix) > */ > if (opts.new_branch && argc == 1) > die(_("Cannot update paths and switch to branch '%s' > at the same time.\n" > - "Did you intend to checkout '%s' which can not > be resolved as commit?"), > + "'%s' can not be resolved as commit, but it > should."), > opts.new_branch, argv[0]); > > if (opts.force_detach) > diff --git a/help.c b/help.c > index bc6cd19cf..4658a55c6 100644 > --- a/help.c > +++ b/help.c > @@ -411,8 +411,8 @@ const char *help_unknown_cmd(const char *cmd) > > if (SIMILAR_ENOUGH(best_similarity)) { > fprintf_ln(stderr, > - Q_("\nDid you mean this?", > - "\nDid you mean one of these?", > + Q_("\nThe most approaching command is", > + "\nThe most approaching commands are", > n)); > > for (i = 0; i < n; i++) > -- > 2.12.0 > > 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. > > 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.
