From: Junio C Hamano <gitster@pobox.com>
To: "Rubén Justo" <rjusto@gmail.com>
Cc: Git List <git@vger.kernel.org>,
Phillip Wood <phillip.wood@dunelm.org.uk>
Subject: Re: [PATCH] add-patch: response to invalid option
Date: Tue, 16 Apr 2024 03:26:33 -0700 [thread overview]
Message-ID: <xmqq5xwhhacm.fsf@gitster.g> (raw)
In-Reply-To: <4e2bc660-ee33-4641-aca5-783d0cefcd23@gmail.com> ("Rubén Justo"'s message of "Mon, 15 Apr 2024 21:00:28 +0200")
Rubén Justo <rjusto@gmail.com> writes:
> When the user introduces an invalid option, we respond with the whole
> help text.
The verb "introduces" in the first sentence looked weird to me.
add -p: require two steps to get help after mistyping an option
During a "git add -p" session, if the user chooses an option
that is not offered, the help text for the entire available
choices is given.
or something, perhaps.
> Instead of displaying the long help description, display a short error
> message indicating the incorrectly introduced option with a note on how
> to get the help text.
When you wanted to 'q'uit but touched the 'w' key that sits next to
it by mistake, you do not need to be told about what any of the
options would do; you may want to be told "the option to quit is
'q', not 'w'", though ;-).
On the other hand, if you are truly lost and do not know what each
of the listed choices mean, you'd type '?' anyway because that is
one of the offered choices. So the only change needed here is to
make sure that '?' is the only thing that gives the help message,
and all other unrecognised option 'x' are made to say "we do not
know 'x'".
That flow of thought makes sort-of sense, if the choices that are
offered are too numerous (say, around a dozen or more), but with the
current command set, I am not sure if this change is an improvement
(note: I did not say "I do not think that"---I simply am not sure).
If we implemented the UI this way 20 years ago in the first version,
perhaps we would have had happily been using it since, but given
that the way we implemented the UI 20 years ago has been used
happily by our users without much complaint, either way must be just
fine.
Is it worth changing it at this point? Does it improve the end-user
experience in any noticeable way? I do not think I can answer these
two questions with confident "yes".
> Signed-off-by: Rubén Justo <rjusto@gmail.com>
> ---
> add-patch.c | 5 ++++-
> t/t3701-add-interactive.sh | 10 ++++++++++
> 2 files changed, 14 insertions(+), 1 deletion(-)
>
> diff --git a/add-patch.c b/add-patch.c
> index a06dd18985..c77902fec5 100644
> --- a/add-patch.c
> +++ b/add-patch.c
> @@ -1667,7 +1667,7 @@ static int patch_update_file(struct add_p_state *s,
> }
> } else if (s->answer.buf[0] == 'p') {
> rendered_hunk_index = -1;
> - } else {
> + } else if (s->answer.buf[0] == '?') {
> const char *p = _(help_patch_remainder), *eol = p;
>
> color_fprintf(stdout, s->s.help_color, "%s",
> @@ -1691,6 +1691,9 @@ static int patch_update_file(struct add_p_state *s,
> color_fprintf_ln(stdout, s->s.help_color,
> "%.*s", (int)(eol - p), p);
> }
> + } else {
> + err(s, _("Unknown option '%s' (use '?' for help)"),
> + s->answer.buf);
> }
> }
>
> diff --git a/t/t3701-add-interactive.sh b/t/t3701-add-interactive.sh
> index bc55255b0a..b38fd5388a 100755
> --- a/t/t3701-add-interactive.sh
> +++ b/t/t3701-add-interactive.sh
> @@ -61,6 +61,16 @@ test_expect_success 'setup (initial)' '
> echo more >>file &&
> echo lines >>file
> '
> +
> +test_expect_success 'invalid option' '
> + cat >expect <<-EOF &&
> + Unknown option ${SQ}W${SQ} (use ${SQ}?${SQ} for help)
> + EOF
> + test_write_lines W |
> + git -c core.filemode=true add -p 2>actual &&
> + test_cmp expect actual
> +'
> +
> test_expect_success 'status works (initial)' '
> git add -i </dev/null >output &&
> grep "+1/-0 *+2/-0 file" output
next prev parent reply other threads:[~2024-04-16 10:26 UTC|newest]
Thread overview: 55+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-04-15 19:00 [PATCH] add-patch: response to invalid option Rubén Justo
2024-04-16 5:51 ` Patrick Steinhardt
2024-04-16 19:11 ` Rubén Justo
2024-04-16 9:41 ` phillip.wood123
2024-04-16 19:24 ` Rubén Justo
2024-04-17 9:37 ` phillip.wood123
2024-04-17 15:05 ` Junio C Hamano
2024-04-18 15:11 ` phillip.wood123
2024-04-16 10:26 ` Junio C Hamano [this message]
2024-04-16 13:56 ` Phillip Wood
2024-04-16 15:22 ` Junio C Hamano
2024-04-16 15:46 ` Phillip Wood
2024-04-16 16:10 ` Junio C Hamano
2024-04-16 19:31 ` Rubén Justo
2024-04-20 11:08 ` [PATCH v2] add-patch: response to invalid command Rubén Justo
2024-04-20 17:53 ` Junio C Hamano
2024-04-21 9:51 ` [PATCH v3] add-patch: response to unknown command Rubén Justo
2024-04-21 13:18 ` phillip.wood123
2024-04-21 19:37 ` Rubén Justo
2024-04-21 21:52 ` [PATCH v4] " Rubén Justo
2024-04-22 15:50 ` Junio C Hamano
2024-04-24 10:15 ` phillip.wood123
2024-04-24 15:35 ` Junio C Hamano
2024-04-29 9:48 ` Phillip Wood
2024-04-29 16:09 ` Junio C Hamano
2024-04-25 1:44 ` Jeff King
2024-04-25 2:15 ` Eric Sunshine
2024-04-25 20:23 ` Junio C Hamano
2024-04-25 21:00 ` Eric Sunshine
2024-04-25 21:13 ` Junio C Hamano
2024-04-25 21:05 ` Junio C Hamano
2024-04-25 22:09 ` Rubén Justo
2024-04-25 22:16 ` Junio C Hamano
2024-04-25 23:46 ` Rubén Justo
2024-04-26 5:39 ` Junio C Hamano
2024-04-26 16:26 ` Junio C Hamano
2024-04-26 20:21 ` Jeff King
2024-04-25 3:04 ` Rubén Justo
2024-04-26 20:23 ` Jeff King
2024-04-26 20:41 ` Rubén Justo
2024-04-25 8:53 ` phillip.wood123
2024-04-29 18:35 ` [PATCH v5 0/2] " Rubén Justo
2024-04-29 18:37 ` [PATCH v5 1/2] add-patch: do not show UI messages on stderr Rubén Justo
2024-04-29 19:24 ` Junio C Hamano
2024-04-30 10:52 ` Jeff King
2024-04-30 16:35 ` Rubén Justo
2024-04-30 17:17 ` Junio C Hamano
2024-04-30 17:11 ` Junio C Hamano
2024-04-30 14:47 ` phillip.wood123
2024-04-30 16:38 ` Rubén Justo
2024-05-01 15:39 ` phillip.wood123
2024-05-01 16:14 ` Junio C Hamano
2024-05-01 21:13 ` Rubén Justo
2024-05-02 16:38 ` Junio C Hamano
2024-04-29 18:37 ` [PATCH v5 2/2] add-patch: response to unknown command Rubén Justo
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=xmqq5xwhhacm.fsf@gitster.g \
--to=gitster@pobox.com \
--cc=git@vger.kernel.org \
--cc=phillip.wood@dunelm.org.uk \
--cc=rjusto@gmail.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.