threads / patch / 61520

patchadd-patch: response to unknown command

Subject: [PATCH] add-patch: response to unknown command

## tl;dr

21 messages between May 21, 2024 and May 23, 2024. Diffs are folded; open one to read it.

replies: 20people: 6as markdown or json

Rubén Justo· May 21, 2024, 00:37 UTC · lore

In 26998ed2a2 (add-patch: response to unknown command, 2024-04-29) we introduced an error message that displays the invalid command entered by the user.

We process a line received from the user, but we only accept single-character commands.

To avoid confusion, include in the error message only the first character received.

Signed-off-by: Rubén Justo <rjusto@gmail.com>
---
 add-patch.c                | 4 ++--
 t/t3701-add-interactive.sh | 2 +-
 2 files changed, 3 insertions(+), 3 deletions(-)
Show changes to 2 files +3 −3

add-patch.c, t/t3701-add-interactive.sh

diff --git a/add-patch.c b/add-patch.c
index 2252895c28..d408a85353 100644
--- a/add-patch.c
+++ b/add-patch.c
@@ -1692,8 +1692,8 @@ static int patch_update_file(struct add_p_state *s,
 						 "%.*s", (int)(eol - p), p);
 			}
 		} else {
-			err(s, _("Unknown command '%s' (use '?' for help)"),
-			    s->answer.buf);
+			err(s, _("Unknown command '%c' (use '?' for help)"),
+			    s->answer.buf[0]);
 		}
 	}
 
diff --git a/t/t3701-add-interactive.sh b/t/t3701-add-interactive.sh
index 28a95a775d..6f5d3085af 100755
--- a/t/t3701-add-interactive.sh
+++ b/t/t3701-add-interactive.sh
@@ -60,7 +60,7 @@ test_expect_success 'warn about add.interactive.useBuiltin' '
 
 test_expect_success 'unknown command' '
 	test_when_finished "git reset --hard; rm -f command" &&
-	echo W >command &&
+	echo WW >command &&
 	git add -N command &&
 	git diff command >expect &&
 	cat >>expect <<-EOF &&
-- 
2.45.1.217.gdb529f37a6
Patrick Steinhardt· May 21, 2024, 07:03 UTC · re: Rubén Justo · lore

Re: [PATCH] add-patch: response to unknown command

On Tue, May 21, 2024 at 02:37:54AM +0200, Rubén Justo wrote:
Show 9 quoted lines
> In 26998ed2a2 (add-patch: response to unknown command, 2024-04-29) we
> introduced an error message that displays the invalid command entered by
> the user.
> 
> We process a line received from the user, but we only accept
> single-character commands.
> 
> To avoid confusion, include in the error message only the first
> character received.

I'm a bit on the edge here. Is it really less confusing if we confront the user with a command that they have never even provided in the first place? They implicitly specified the first letter, only, but the user first needs to be aware that we discard everything but the first letter in the first place.

Is it even sensible that we don't complain about trailing garbage in the user's answer? Shouldn't we rather fix that and make the accepted answers more strict, such that if the response is longer than a single character we point that out?

Patrick
Rubén Justo· May 21, 2024, 12:59 UTC · re: Patrick Steinhardt · lore

Re: [PATCH] add-patch: response to unknown command

On Tue, May 21, 2024 at 09:03:08AM +0200, Patrick Steinhardt wrote:
Show 14 quoted lines
> On Tue, May 21, 2024 at 02:37:54AM +0200, Rubén Justo wrote:
> > In 26998ed2a2 (add-patch: response to unknown command, 2024-04-29) we
> > introduced an error message that displays the invalid command entered by
> > the user.
> > 
> > We process a line received from the user, but we only accept
> > single-character commands.
> > 
> > To avoid confusion, include in the error message only the first
> > character received.
> 
> I'm a bit on the edge here. Is it really less confusing if we confront
> the user with a command that they have never even provided in the first
> place?

I think so, by giving the user what we find wrong and implicitly telling them what it is.

> Shouldn't we rather fix that and make the accepted
> answers more strict, such that if the response is longer than a single
> character we point that out?
That's reasonable, but maybe we're going to break someone's workflow?
At any rate, my main goal is to avoid the '%s' in the message.
> 
> Patrick
Junio C Hamano· May 21, 2024, 15:52 UTC · re: Patrick Steinhardt · lore

Re* [PATCH] add-patch: response to unknown command

Patrick Steinhardt <ps@pks.im> writes:
Show 5 quoted lines
> I'm a bit on the edge here. Is it really less confusing if we confront
> the user with a command that they have never even provided in the first
> place? They implicitly specified the first letter, only, but the user
> first needs to be aware that we discard everything but the first letter
> in the first place.

I share your doubt. If what the user said (e.g. "ues") when they wanted to say "yes", I find "You said 'u', which I do not understand" more confusiong than "You said 'ues', which I do not understand".

> Is it even sensible that we don't complain about trailing garbage in the
> user's answer? Shouldn't we rather fix that and make the accepted
> answers more strict, such that if the response is longer than a single
> character we point that out?

I personally guess that it is unlikely that folks are taking advantage of the fact that everything but the first is ignored, and I cannot think of a reason why folks prefer that behaviour offhand.

If 'q' and 'a' are next to each other on the user's keyboard, there is a plausible chance that we see 'qa' when the user who wanted to say 'a' fat-fingered and we ended up doing the 'q' thing instead, and we may want to prevent such problems from happening.

Instead of ignoring, we _could_ take 'yn' and apply 'y' to the current question, and then 'n' to the next question without prompting (or showing prompt and answer together without taking further answer), and claim that it is a typesaving feature, but it is dubious users can sensibly choose the answer to a prompt they haven't seen.

So, I am inclined to be supportive on that "tighten multi-byte input" idea, but as I said the above is based on a mere "I cannot think of ... offhand", so we need to see if people have reasonable use cases to object first.

------- >8 ------------- >8 ------------- >8 ------------- >8 -------
Subject: add-patch: enforce only one-letter response to prompts

In an "git add -p" session, especially when we are not using the single-char mode, we may see 'qa' as a response to a prompt

  (1/2) Stage this hunk [y,n,q,a,d,j,J,g,/,e,p,?]?

and then just do the 'q' thing (i.e. quit the session), ignoring everything other than the first byte.

If 'q' and 'a' are next to each other on the user's keyboard, there is a plausible chance that we see 'qa' when the user who wanted to say 'a' fat-fingered and we ended up doing the 'q' thing instead.

As we didn't think of a good reason during the review discussion why we want to accept excess letters only to ignore them, it appears to be a safe change to simply reject input that is longer than just one byte.

Keep the "use only the first byte, downcased" behaviour when we ask yes/no question, though. Neither on Qwerty or on Dvorak, 'y' and 'n' are not close to each other.

Signed-off-by: Junio C Hamano <gitster@pobox.com>
---
 add-patch.c | 5 +++++
 1 file changed, 5 insertions(+)
Show changes to diff +5 −0
diff --git c/add-patch.c w/add-patch.c
index 2252895c28..7126bc5d70 100644
--- c/add-patch.c
+++ w/add-patch.c
@@ -1227,6 +1227,7 @@ static int prompt_yesno(struct add_p_state *s, const char *prompt)
 		fflush(stdout);
 		if (read_single_character(s) == EOF)
 			return -1;
+		/* do not limit to 1-byte input to allow 'no' etc. */
 		switch (tolower(s->answer.buf[0])) {
 		case 'n': return 0;
 		case 'y': return 1;
@@ -1509,6 +1510,10 @@ static int patch_update_file(struct add_p_state *s,
 
 		if (!s->answer.len)
 			continue;
+		if (1 < s->answer.len) {
+			error(_("only one letter is expected, got '%s'"), s->answer.buf);
+			continue;
+		}
 		ch = tolower(s->answer.buf[0]);
 		if (ch == 'y') {
 			hunk->use = USE_HUNK;
Taylor Blau· May 21, 2024, 22:27 UTC · re: Junio C Hamano · lore

Re: Re* [PATCH] add-patch: response to unknown command

On Tue, May 21, 2024 at 08:52:14AM -0700, Junio C Hamano wrote:
Show 11 quoted lines
> Patrick Steinhardt <ps@pks.im> writes:
>
> > I'm a bit on the edge here. Is it really less confusing if we confront
> > the user with a command that they have never even provided in the first
> > place? They implicitly specified the first letter, only, but the user
> > first needs to be aware that we discard everything but the first letter
> > in the first place.
>
> I share your doubt.  If what the user said (e.g. "ues") when they
> wanted to say "yes", I find "You said 'u', which I do not understand"
> more confusiong than "You said 'ues', which I do not understand".
Same here. The below patch provides compelling reasoning and has my:
  Acked-by: Taylor Blau <me@ttaylorr.com>

Thanks, Taylor

Junio C Hamano· May 21, 2024, 23:06 UTC · re: Taylor Blau · lore

Re: Re* [PATCH] add-patch: response to unknown command

Taylor Blau <me@ttaylorr.com> writes:
Show 8 quoted lines
>>
>> I share your doubt.  If what the user said (e.g. "ues") when they
>> wanted to say "yes", I find "You said 'u', which I do not understand"
>> more confusiong than "You said 'ues', which I do not understand".
>
> Same here. The below patch provides compelling reasoning and has my:
>
>   Acked-by: Taylor Blau <me@ttaylorr.com>

Heh, this breaks '/' command hence t3701.45 as it takes an argument hence not limited to a single letter. I wonder how singlekey folks invoke that feature, though ;-)

Junio C Hamano· May 21, 2024, 23:20 UTC · re: Junio C Hamano · lore

[PATCH v2] add-patch: enforce only one-letter response to prompts

In an "git add -p" session, especially when we are not using the single-char mode, we may see 'qa' as a response to a prompt

  (1/2) Stage this hunk [y,n,q,a,d,j,J,g,/,e,p,?]?

and then just do the 'q' thing (i.e. quit the session), ignoring everything other than the first byte.

If 'q' and 'a' are next to each other on the user's keyboard, there is a plausible chance that we see 'qa' when the user who wanted to say 'a' fat-fingered and we ended up doing the 'q' thing instead.

As we didn't think of a good reason during the review discussion why we want to accept excess letters only to ignore them, it appears to be a safe change to simply reject input that is longer than just one byte.

The two exceptions are the 'g' command that takes a hunk number, and the '/' command that takes a regular expression. They has to be accompanied by their operands (this makes me wonder how users who set the interactive.singlekey configuration feed these operands---it turns out that we notice there is no operand and give them another chance to type the operand separately, without using single key input this time), so we accept a string that is more than one byte long.

Keep the "use only the first byte, downcased" behaviour when we ask yes/no question, though. Neither on Qwerty or on Dvorak, 'y' and 'n' are not close to each other.

Signed-off-by: Junio C Hamano <gitster@pobox.com>
---
 * This version fixes the breakage in t3701 where we exercise the
   '/' command.  Further code inspection reveals that 'g' also needs
   to be special cased.
   The previous iteration was <xmqqr0dvb1sh.fsf_-_@gitster.g>.
 add-patch.c | 7 +++++++
 1 file changed, 7 insertions(+)
Show changes to add-patch.c +7 −0
diff --git a/add-patch.c b/add-patch.c
index 79eda168eb..a6c3367d59 100644
--- a/add-patch.c
+++ b/add-patch.c
@@ -1228,6 +1228,7 @@ static int prompt_yesno(struct add_p_state *s, const char *prompt)
 		fflush(stdout);
 		if (read_single_character(s) == EOF)
 			return -1;
+		/* do not limit to 1-byte input to allow 'no' etc. */
 		switch (tolower(s->answer.buf[0])) {
 		case 'n': return 0;
 		case 'y': return 1;
@@ -1506,6 +1507,12 @@ static int patch_update_file(struct add_p_state *s,
 		if (!s->answer.len)
 			continue;
 		ch = tolower(s->answer.buf[0]);
+
+		/* 'g' takes a hunk number, '/' takes a regexp */
+		if (1 < s->answer.len && (ch != 'g' && ch != '/')) {
+			error(_("only one letter is expected, got '%s'"), s->answer.buf);
+			continue;
+		}
 		if (ch == 'y') {
 			hunk->use = USE_HUNK;
 soft_increment:
-- 
2.45.1-216-g4365c6fcf9
Eric Sunshine· May 21, 2024, 23:36 UTC · re: Junio C Hamano · lore

Re: [PATCH v2] add-patch: enforce only one-letter response to prompts

On Tue, May 21, 2024 at 7:20 PM Junio C Hamano <gitster@pobox.com> wrote:
Show 19 quoted lines
> In an "git add -p" session, especially when we are not using the
> single-char mode, we may see 'qa' as a response to a prompt
>
>   (1/2) Stage this hunk [y,n,q,a,d,j,J,g,/,e,p,?]?
>
> and then just do the 'q' thing (i.e. quit the session), ignoring
> everything other than the first byte.
>
> If 'q' and 'a' are next to each other on the user's keyboard, there
> is a plausible chance that we see 'qa' when the user who wanted to
> say 'a' fat-fingered and we ended up doing the 'q' thing instead.
>
> As we didn't think of a good reason during the review discussion why
> we want to accept excess letters only to ignore them, it appears to
> be a safe change to simply reject input that is longer than just one
> byte.
>
> The two exceptions are the 'g' command that takes a hunk number, and
> the '/' command that takes a regular expression.  They has to be
s/has/have/
Show 12 quoted lines
> accompanied by their operands (this makes me wonder how users who
> set the interactive.singlekey configuration feed these operands---it
> turns out that we notice there is no operand and give them another
> chance to type the operand separately, without using single key
> input this time), so we accept a string that is more than one byte
> long.
>
> Keep the "use only the first byte, downcased" behaviour when we ask
> yes/no question, though.  Neither on Qwerty or on Dvorak, 'y' and
> 'n' are not close to each other.
>
> Signed-off-by: Junio C Hamano <gitster@pobox.com>
Junio C Hamano· May 22, 2024, 00:49 UTC · re: Eric Sunshine · lore

Re: [PATCH v2] add-patch: enforce only one-letter response to prompts

Eric Sunshine <sunshine@sunshineco.com> writes:
>> The two exceptions are the 'g' command that takes a hunk number, and
>> the '/' command that takes a regular expression.  They has to be
>
> s/has/have/
Thanks for a typofix.
Input to possibly update this part ...
>> As we didn't think of a good reason during the review discussion why
>> we want to accept excess letters only to ignore them,...

... of the proposed log message, or convince us that it is not such a great idea, is also welcome.

Thanks.  Will queue but keep out of 'next' for a few more days.
Dragan Simic· May 22, 2024, 06:40 UTC · re: Junio C Hamano · lore

Re: [PATCH v2] add-patch: enforce only one-letter response to prompts

Hello Junio,
Please see my comments below.
On 2024-05-22 01:20, Junio C Hamano wrote:
> In an "git add -p" session, especially when we are not using the
s/In an/In a/
> single-char mode, we may see 'qa' as a response to a prompt
Perhaps s/single-char/single-character/
Show 60 quoted lines
> 
>   (1/2) Stage this hunk [y,n,q,a,d,j,J,g,/,e,p,?]?
> 
> and then just do the 'q' thing (i.e. quit the session), ignoring
> everything other than the first byte.
> 
> If 'q' and 'a' are next to each other on the user's keyboard, there
> is a plausible chance that we see 'qa' when the user who wanted to
> say 'a' fat-fingered and we ended up doing the 'q' thing instead.
> 
> As we didn't think of a good reason during the review discussion why
> we want to accept excess letters only to ignore them, it appears to
> be a safe change to simply reject input that is longer than just one
> byte.
> 
> The two exceptions are the 'g' command that takes a hunk number, and
> the '/' command that takes a regular expression.  They has to be
> accompanied by their operands (this makes me wonder how users who
> set the interactive.singlekey configuration feed these operands---it
> turns out that we notice there is no operand and give them another
> chance to type the operand separately, without using single key
> input this time), so we accept a string that is more than one byte
> long.
> 
> Keep the "use only the first byte, downcased" behaviour when we ask
> yes/no question, though.  Neither on Qwerty or on Dvorak, 'y' and
> 'n' are not close to each other.
> 
> Signed-off-by: Junio C Hamano <gitster@pobox.com>
> ---
>  * This version fixes the breakage in t3701 where we exercise the
>    '/' command.  Further code inspection reveals that 'g' also needs
>    to be special cased.
> 
>    The previous iteration was <xmqqr0dvb1sh.fsf_-_@gitster.g>.
> 
>  add-patch.c | 7 +++++++
>  1 file changed, 7 insertions(+)
> 
> diff --git a/add-patch.c b/add-patch.c
> index 79eda168eb..a6c3367d59 100644
> --- a/add-patch.c
> +++ b/add-patch.c
> @@ -1228,6 +1228,7 @@ static int prompt_yesno(struct add_p_state *s,
> const char *prompt)
>  		fflush(stdout);
>  		if (read_single_character(s) == EOF)
>  			return -1;
> +		/* do not limit to 1-byte input to allow 'no' etc. */
>  		switch (tolower(s->answer.buf[0])) {
>  		case 'n': return 0;
>  		case 'y': return 1;
> @@ -1506,6 +1507,12 @@ static int patch_update_file(struct add_p_state 
> *s,
>  		if (!s->answer.len)
>  			continue;
>  		ch = tolower(s->answer.buf[0]);
> +
> +		/* 'g' takes a hunk number, '/' takes a regexp */
> +		if (1 < s->answer.len && (ch != 'g' && ch != '/')) {

To me, "s->answer.len > 1" would be much more readable, and I was surprised a bit to see the flipped variant. This made me curious; would you, please, let me know why do you prefer this form?

Show 6 quoted lines
> +			error(_("only one letter is expected, got '%s'"), s->answer.buf);
> +			continue;
> +		}
>  		if (ch == 'y') {
>  			hunk->use = USE_HUNK;
>  soft_increment:

The patch is looking good to me, and I find it good that it improves the strictness of the user input, which should also improve the overall user experience.

Junio C Hamano· May 22, 2024, 16:23 UTC · re: Dragan Simic · lore

Re: [PATCH v2] add-patch: enforce only one-letter response to prompts

Dragan Simic <dsimic@manjaro.org> writes:
Show 8 quoted lines
> Hello Junio,
>
> Please see my comments below.
>
> On 2024-05-22 01:20, Junio C Hamano wrote:
>> In an "git add -p" session, especially when we are not using the
>
> s/In an/In a/
Good eyes.
>
>> single-char mode, we may see 'qa' as a response to a prompt
>
> Perhaps s/single-char/single-character/

I shouldn't have been loose in the language. Rather, we should say "single key mode", as the knob to control the feature is the "interactive.singlekey" variable.

Show 7 quoted lines
>> +		/* 'g' takes a hunk number, '/' takes a regexp */
>> +		if (1 < s->answer.len && (ch != 'g' && ch != '/')) {
>
> To me, "s->answer.len > 1" would be much more readable, and
> I was surprised a bit to see the flipped variant.  This made
> me curious; would you, please, let me know why do you prefer
> this form?
"textual order should reflect actual order" (read CodingGuidelines).
For more backstory,
    https://lore.kernel.org/git/?q=%22textual+order%22+%22actual+order%22
Thanks.
Dragan Simic· May 22, 2024, 19:03 UTC · re: Junio C Hamano · lore

Re: [PATCH v2] add-patch: enforce only one-letter response to prompts

On 2024-05-22 18:23, Junio C Hamano wrote:
Show 9 quoted lines
> Dragan Simic <dsimic@manjaro.org> writes:
>> On 2024-05-22 01:20, Junio C Hamano wrote:
>>> single-char mode, we may see 'qa' as a response to a prompt
>> 
>> Perhaps s/single-char/single-character/
> 
> I shouldn't have been loose in the language.  Rather, we should say
> "single key mode", as the knob to control the feature is the
> "interactive.singlekey" variable.

Yes, "single-key mode" is better; "when interactive.singlekey is not enabled" may be even a bit better. Not worth a reroll, of course.

Show 14 quoted lines
>>> +		/* 'g' takes a hunk number, '/' takes a regexp */
>>> +		if (1 < s->answer.len && (ch != 'g' && ch != '/')) {
>> 
>> To me, "s->answer.len > 1" would be much more readable, and
>> I was surprised a bit to see the flipped variant.  This made
>> me curious; would you, please, let me know why do you prefer
>> this form?
> 
> "textual order should reflect actual order" (read CodingGuidelines).
> 
> For more backstory,
> 
>     
> https://lore.kernel.org/git/?q=%22textual+order%22+%22actual+order%22

That's exactly what I assumed, but frankly, in this particular case I really can't force myself, despite trying quite hard, into liking it. It's simply strange to me.

Junio C Hamano· May 22, 2024, 20:41 UTC · re: Dragan Simic · lore

Re: [PATCH v2] add-patch: enforce only one-letter response to prompts

Dragan Simic <dsimic@manjaro.org> writes:
Show 6 quoted lines
>> For more backstory,
>>     https://lore.kernel.org/git/?q=%22textual+order%22+%22actual+order%22
>
> That's exactly what I assumed, but frankly, in this particular case
> I really can't force myself, despite trying quite hard, into liking
> it.  It's simply strange to me.
You asked me why, and the reason was given to you.  End of story.
I never asked you to like it and you do not have to like it ;-).
Patrick Steinhardt· May 22, 2024, 11:07 UTC · re: Junio C Hamano · lore

Re: [PATCH v2] add-patch: enforce only one-letter response to prompts

On Tue, May 21, 2024 at 04:20:16PM -0700, Junio C Hamano wrote:
Show 11 quoted lines
> In an "git add -p" session, especially when we are not using the
> single-char mode, we may see 'qa' as a response to a prompt
> 
>   (1/2) Stage this hunk [y,n,q,a,d,j,J,g,/,e,p,?]?
> 
> and then just do the 'q' thing (i.e. quit the session), ignoring
> everything other than the first byte.
> 
> If 'q' and 'a' are next to each other on the user's keyboard, there
> is a plausible chance that we see 'qa' when the user who wanted to
> say 'a' fat-fingered and we ended up doing the 'q' thing instead.

I think it's a good idea regardless of the layout. There are tons of layouts out there that are very esoteric (I for one use NEO2, which most nobody has ever heard of), and I'm sure you will find at least one layout where characters are positioned such that you can fat finger things.

Another argument that is independent of fat fingering is that it potentially allows us to expand this feature with multi-byte verbs going forward.

[snip]
> Keep the "use only the first byte, downcased" behaviour when we ask
> yes/no question, though.  Neither on Qwerty or on Dvorak, 'y' and
> 'n' are not close to each other.

Just to prove my point: Workman layout has them right next to each other :) What we make of that information is a different question though.

Show 19 quoted lines
> diff --git a/add-patch.c b/add-patch.c
> index 79eda168eb..a6c3367d59 100644
> --- a/add-patch.c
> +++ b/add-patch.c
> @@ -1228,6 +1228,7 @@ static int prompt_yesno(struct add_p_state *s, const char *prompt)
>  		fflush(stdout);
>  		if (read_single_character(s) == EOF)
>  			return -1;
> +		/* do not limit to 1-byte input to allow 'no' etc. */
>  		switch (tolower(s->answer.buf[0])) {
>  		case 'n': return 0;
>  		case 'y': return 1;
> @@ -1506,6 +1507,12 @@ static int patch_update_file(struct add_p_state *s,
>  		if (!s->answer.len)
>  			continue;
>  		ch = tolower(s->answer.buf[0]);
> +
> +		/* 'g' takes a hunk number, '/' takes a regexp */
> +		if (1 < s->answer.len && (ch != 'g' && ch != '/')) {

I find this condition a bit unusual and thus hard to read. If it instead said `s->answer.len != 1` then it would be way easier to comprehend.

Also, none of the branches othar than for 'g' and '/' use `s->answer`, so this should be safe. I also very much agree with the general idea of this patch.

Show 6 quoted lines
> +			error(_("only one letter is expected, got '%s'"), s->answer.buf);
> +			continue;
> +		}
>  		if (ch == 'y') {
>  			hunk->use = USE_HUNK;
>  soft_increment:
I assume we also want a test for this new behaviour, right?
Patrick
Junio C Hamano· May 22, 2024, 16:27 UTC · re: Patrick Steinhardt · lore

Re: [PATCH v2] add-patch: enforce only one-letter response to prompts

Patrick Steinhardt <ps@pks.im> writes:
Show 5 quoted lines
>> +		/* 'g' takes a hunk number, '/' takes a regexp */
>> +		if (1 < s->answer.len && (ch != 'g' && ch != '/')) {
>
> I find this condition a bit unusual and thus hard to read. If it instead
> said `s->answer.len != 1` then it would be way easier to comprehend.

We have already eliminated the "it is 0" case, .len cannot be negative, and the case we really care about is "is it not just one?", so I agree with you that the inequality comparison with 1 is easier to grok.

> I assume we also want a test for this new behaviour, right?

Hmph, yeah. 'g' has already been tested (that was what led me to do the v2), but we probably should do 'qa' or something.

Thanks.
Junio C Hamano· May 22, 2024, 17:14 UTC · re: Junio C Hamano · lore

[PATCH v3] add-patch: enforce only one-letter response to prompts

In a "git add -p" session, especially when we are not using the single-key mode, we may see 'qa' as a response to a prompt

  (1/2) Stage this hunk [y,n,q,a,d,j,J,g,/,e,p,?]?

and then just do the 'q' thing (i.e. quit the session), ignoring everything other than the first byte.

If 'q' and 'a' are next to each other on the user's keyboard, there is a plausible chance that we see 'qa' when the user who wanted to say 'a' fat-fingered and we ended up doing the 'q' thing instead.

As we didn't think of a good reason during the review discussion why we want to accept excess letters only to ignore them, it appears to be a safe change to simply reject input that is longer than just one byte.

The two exceptions are the 'g' command that takes a hunk number, and the '/' command that takes a regular expression. They have to be accompanied by their operands (this makes me wonder how users who set the interactive.singlekey configuration feed these operands---it turns out that we notice there is no operand and give them another chance to type the operand separately, without using single key input this time), so we accept a string that is more than one byte long.

Keep the "use only the first byte, downcased" behaviour when we ask yes/no question, though. Neither on Qwerty or on Dvorak, 'y' and 'n' are not close to each other.

Signed-off-by: Junio C Hamano <gitster@pobox.com>
---
 The whole range-diff is not worth sharing as the bulk of it show
 the new tests.  The part that shows the changes to the proposed log
 message and the code looks like this:
    @@ Metadata
      ## Commit message ##
         add-patch: enforce only one-letter response to prompts
     
    -    In an "git add -p" session, especially when we are not using the
    -    single-char mode, we may see 'qa' as a response to a prompt
    +    In a "git add -p" session, especially when we are not using the
    +    single-key mode, we may see 'qa' as a response to a prompt
     
           (1/2) Stage this hunk [y,n,q,a,d,j,J,g,/,e,p,?]?
     
    @@ add-patch.c: static int patch_update_file(struct add_p_state *s,
      			continue;
      		ch = tolower(s->answer.buf[0]);
     +
    -+		/* 'g' takes a hunk number, '/' takes a regexp */
    -+		if (1 < s->answer.len && (ch != 'g' && ch != '/')) {
    ++		/* 'g' takes a hunk number and '/' takes a regexp */
    ++		if (s->answer.len != 1 && (ch != 'g' && ch != '/')) {
     +			error(_("only one letter is expected, got '%s'"), s->answer.buf);
     +			continue;
     +		}
      		if (ch == 'y') {
      			hunk->use = USE_HUNK;
      soft_increment:
     
 add-patch.c                |  7 +++++++
 t/t3701-add-interactive.sh | 38 ++++++++++++++++++++++++++++++++++++--
 2 files changed, 43 insertions(+), 2 deletions(-)
Show changes to 2 files +43 −2

add-patch.c, t/t3701-add-interactive.sh

diff --git a/add-patch.c b/add-patch.c
index 79eda168eb..7242da2c03 100644
--- a/add-patch.c
+++ b/add-patch.c
@@ -1228,6 +1228,7 @@ static int prompt_yesno(struct add_p_state *s, const char *prompt)
 		fflush(stdout);
 		if (read_single_character(s) == EOF)
 			return -1;
+		/* do not limit to 1-byte input to allow 'no' etc. */
 		switch (tolower(s->answer.buf[0])) {
 		case 'n': return 0;
 		case 'y': return 1;
@@ -1506,6 +1507,12 @@ static int patch_update_file(struct add_p_state *s,
 		if (!s->answer.len)
 			continue;
 		ch = tolower(s->answer.buf[0]);
+
+		/* 'g' takes a hunk number and '/' takes a regexp */
+		if (s->answer.len != 1 && (ch != 'g' && ch != '/')) {
+			error(_("only one letter is expected, got '%s'"), s->answer.buf);
+			continue;
+		}
 		if (ch == 'y') {
 			hunk->use = USE_HUNK;
 soft_increment:
diff --git a/t/t3701-add-interactive.sh b/t/t3701-add-interactive.sh
index 0b5339ac6c..61f5e9eec0 100755
--- a/t/t3701-add-interactive.sh
+++ b/t/t3701-add-interactive.sh
@@ -144,6 +144,14 @@ test_expect_success 'revert works (commit)' '
 	grep "unchanged *+3/-0 file" output
 '
 
+test_expect_success 'reject multi-key input' '
+	saved=$(git hash-object -w file) &&
+	test_when_finished "git cat-file blob $saved >file" &&
+	echo an extra line >>file &&
+	test_write_lines aa | git add -p >actual 2>error &&
+	test_grep "error: .* got ${SQ}aa${SQ}" error
+'
+
 test_expect_success 'setup expected' '
 	cat >expected <<-\EOF
 	EOF
@@ -511,7 +519,7 @@ test_expect_success 'split hunk setup' '
 	test_write_lines 10 15 20 21 22 23 24 30 40 50 60 >test
 '
 
-test_expect_success 'goto hunk' '
+test_expect_success 'goto hunk 1 with "g 1"' '
 	test_when_finished "git reset" &&
 	tr _ " " >expect <<-EOF &&
 	(2/2) Stage this hunk [y,n,q,a,d,K,g,/,e,?]? + 1:  -1,2 +1,3          +15
@@ -527,7 +535,20 @@ test_expect_success 'goto hunk' '
 	test_cmp expect actual.trimmed
 '
 
-test_expect_success 'navigate to hunk via regex' '
+test_expect_success 'goto hunk 1 with "g1"' '
+	test_when_finished "git reset" &&
+	tr _ " " >expect <<-EOF &&
+	_10
+	+15
+	_20
+	(1/2) Stage this hunk [y,n,q,a,d,j,J,g,/,e,?]?_
+	EOF
+	test_write_lines s y g1 | git add -p >actual &&
+	tail -n 4 <actual >actual.trimmed &&
+	test_cmp expect actual.trimmed
+'
+
+test_expect_success 'navigate to hunk via regex /pattern' '
 	test_when_finished "git reset" &&
 	tr _ " " >expect <<-EOF &&
 	(2/2) Stage this hunk [y,n,q,a,d,K,g,/,e,?]? @@ -1,2 +1,3 @@
@@ -541,6 +562,19 @@ test_expect_success 'navigate to hunk via regex' '
 	test_cmp expect actual.trimmed
 '
 
+test_expect_success 'navigate to hunk via regex / pattern' '
+	test_when_finished "git reset" &&
+	tr _ " " >expect <<-EOF &&
+	_10
+	+15
+	_20
+	(1/2) Stage this hunk [y,n,q,a,d,j,J,g,/,e,?]?_
+	EOF
+	test_write_lines s y / 1,2 | git add -p >actual &&
+	tail -n 4 <actual >actual.trimmed &&
+	test_cmp expect actual.trimmed
+'
+
 test_expect_success 'split hunk "add -p (edit)"' '
 	# Split, say Edit and do nothing.  Then:
 	#
-- 
2.45.1-216-g4365c6fcf9
Rubén Justo· May 22, 2024, 17:38 UTC · re: Junio C Hamano · lore

Re: [PATCH v3] add-patch: enforce only one-letter response to prompts

On Wed, May 22, 2024 at 10:14:23AM -0700, Junio C Hamano wrote:
> +		if (s->answer.len != 1 && (ch != 'g' && ch != '/')) {
This "len!=1" introduces a nice dose of sanity in the UI.
> +			error(_("only one letter is expected, got '%s'"), s->answer.buf);
Here, perhaps you want to do:
			err(s, _("Only one letter is expected, got '%s'"), s->answer.buf);
Junio C Hamano· May 22, 2024, 19:27 UTC · re: Rubén Justo · lore

Re: [PATCH v3] add-patch: enforce only one-letter response to prompts

Rubén Justo <rjusto@gmail.com> writes:
> Here, perhaps you want to do:
>
> 			err(s, _("Only one letter is expected, got '%s'"), s->answer.buf);

True. The end-user errors are reported with err() in the surrounding code.

I however was hoping that this can be based on v2.44.0, which predates 9d225b02 (add-patch: do not show UI messages on stderr, 2024-04-29), which makes the testing of it a bit cumbersome.

Junio C Hamano· May 22, 2024, 21:45 UTC · re: Junio C Hamano · lore

[PATCH v4] add-patch: enforce only one-letter response to prompts

In a "git add -p" session, especially when we are not using the single-key mode, we may see 'qa' as a response to a prompt

  (1/2) Stage this hunk [y,n,q,a,d,j,J,g,/,e,p,?]?

and then just do the 'q' thing (i.e. quit the session), ignoring everything other than the first byte.

If 'q' and 'a' are next to each other on the user's keyboard, there is a plausible chance that we see 'qa' when the user who wanted to say 'a' fat-fingered and we ended up doing the 'q' thing instead.

As we didn't think of a good reason during the review discussion why we want to accept excess letters only to ignore them, it appears to be a safe change to simply reject input that is longer than just one byte.

The two exceptions are the 'g' command that takes a hunk number, and the '/' command that takes a regular expression. They have to be accompanied by their operands (this makes me wonder how users who set the interactive.singlekey configuration feed these operands---it turns out that we notice there is no operand and give them another chance to type the operand separately, without using single key input this time), so we accept a string that is more than one byte long.

Keep the "use only the first byte, downcased" behaviour when we ask yes/no question, though. Neither on Qwerty or on Dvorak, 'y' and 'n' are not close to each other.

Signed-off-by: Junio C Hamano <gitster@pobox.com>
---
 * Hopefully the final iteration.  The differences are:
   - The end-user facing "here is what is wrong with your input"
     message is given with err() to be consistent with other such
     messages.
   - I gave up basing this on v2.44.0, as it is a new feature that
     does not have to be merged down to older maintenance tracks.
     This is now based on 80dbfac2 (Merge branch
     'rj/add-p-typo-reaction', 2024-05-08), which is before v2.45.1
     but has modern enough t3701 and add-patch.c:err() sends its
     output to the standard output stream.
   - The tests for 'g' and '/' to check both the stuck and the split
     forms have been updated for the more recent prompt that
     includes 'p'.
   - The test for multi-key sequence expects the err() output on the
     standard output stream.
   As an experiment, this message has the range-diff at the end, not
   before the primary part of the patch text.  I think this format
   should be easier to read for reviewers.
 add-patch.c                |  7 +++++++
 t/t3701-add-interactive.sh | 38 ++++++++++++++++++++++++++++++++++++--
 2 files changed, 43 insertions(+), 2 deletions(-)
Show changes to 2 files +43 −2

add-patch.c, t/t3701-add-interactive.sh

diff --git a/add-patch.c b/add-patch.c
index 2252895c28..814de57c4a 100644
--- a/add-patch.c
+++ b/add-patch.c
@@ -1227,6 +1227,7 @@ static int prompt_yesno(struct add_p_state *s, const char *prompt)
 		fflush(stdout);
 		if (read_single_character(s) == EOF)
 			return -1;
+		/* do not limit to 1-byte input to allow 'no' etc. */
 		switch (tolower(s->answer.buf[0])) {
 		case 'n': return 0;
 		case 'y': return 1;
@@ -1510,6 +1511,12 @@ static int patch_update_file(struct add_p_state *s,
 		if (!s->answer.len)
 			continue;
 		ch = tolower(s->answer.buf[0]);
+
+		/* 'g' takes a hunk number and '/' takes a regexp */
+		if (s->answer.len != 1 && (ch != 'g' && ch != '/')) {
+			err(s, _("Only one letter is expected, got '%s'"), s->answer.buf);
+			continue;
+		}
 		if (ch == 'y') {
 			hunk->use = USE_HUNK;
 soft_increment:
diff --git a/t/t3701-add-interactive.sh b/t/t3701-add-interactive.sh
index 28a95a775d..6624a4f7c0 100755
--- a/t/t3701-add-interactive.sh
+++ b/t/t3701-add-interactive.sh
@@ -160,6 +160,14 @@ test_expect_success 'revert works (commit)' '
 	grep "unchanged *+3/-0 file" output
 '
 
+test_expect_success 'reject multi-key input' '
+	saved=$(git hash-object -w file) &&
+	test_when_finished "git cat-file blob $saved >file" &&
+	echo an extra line >>file &&
+	test_write_lines aa | git add -p >actual &&
+	test_grep "is expected, got ${SQ}aa${SQ}" actual
+'
+
 test_expect_success 'setup expected' '
 	cat >expected <<-\EOF
 	EOF
@@ -526,7 +534,7 @@ test_expect_success 'split hunk setup' '
 	test_write_lines 10 15 20 21 22 23 24 30 40 50 60 >test
 '
 
-test_expect_success 'goto hunk' '
+test_expect_success 'goto hunk 1 with "g 1"' '
 	test_when_finished "git reset" &&
 	tr _ " " >expect <<-EOF &&
 	(2/2) Stage this hunk [y,n,q,a,d,K,g,/,e,p,?]? + 1:  -1,2 +1,3          +15
@@ -542,7 +550,20 @@ test_expect_success 'goto hunk' '
 	test_cmp expect actual.trimmed
 '
 
-test_expect_success 'navigate to hunk via regex' '
+test_expect_success 'goto hunk 1 with "g1"' '
+	test_when_finished "git reset" &&
+	tr _ " " >expect <<-EOF &&
+	_10
+	+15
+	_20
+	(1/2) Stage this hunk [y,n,q,a,d,j,J,g,/,e,p,?]?_
+	EOF
+	test_write_lines s y g1 | git add -p >actual &&
+	tail -n 4 <actual >actual.trimmed &&
+	test_cmp expect actual.trimmed
+'
+
+test_expect_success 'navigate to hunk via regex /pattern' '
 	test_when_finished "git reset" &&
 	tr _ " " >expect <<-EOF &&
 	(2/2) Stage this hunk [y,n,q,a,d,K,g,/,e,p,?]? @@ -1,2 +1,3 @@
@@ -556,6 +577,19 @@ test_expect_success 'navigate to hunk via regex' '
 	test_cmp expect actual.trimmed
 '
 
+test_expect_success 'navigate to hunk via regex / pattern' '
+	test_when_finished "git reset" &&
+	tr _ " " >expect <<-EOF &&
+	_10
+	+15
+	_20
+	(1/2) Stage this hunk [y,n,q,a,d,j,J,g,/,e,p,?]?_
+	EOF
+	test_write_lines s y / 1,2 | git add -p >actual &&
+	tail -n 4 <actual >actual.trimmed &&
+	test_cmp expect actual.trimmed
+'
+
 test_expect_success 'split hunk "add -p (edit)"' '
 	# Split, say Edit and do nothing.  Then:
 	#
-- 
2.45.1-216-g4365c6fcf9

(Range diff relative to v3)

1:  13d42e5db6 ! 1:  de62120664 add-patch: enforce only one-letter response to prompts
    @@ add-patch.c: static int patch_update_file(struct add_p_state *s,
     +
     +		/* 'g' takes a hunk number and '/' takes a regexp */
     +		if (s->answer.len != 1 && (ch != 'g' && ch != '/')) {
    -+			error(_("only one letter is expected, got '%s'"), s->answer.buf);
    ++			err(s, _("Only one letter is expected, got '%s'"), s->answer.buf);
     +			continue;
     +		}
      		if (ch == 'y') {
    @@ t/t3701-add-interactive.sh: test_expect_success 'revert works (commit)' '
     +	saved=$(git hash-object -w file) &&
     +	test_when_finished "git cat-file blob $saved >file" &&
     +	echo an extra line >>file &&
    -+	test_write_lines aa | git add -p >actual 2>error &&
    -+	test_grep "error: .* got ${SQ}aa${SQ}" error
    ++	test_write_lines aa | git add -p >actual &&
    ++	test_grep "is expected, got ${SQ}aa${SQ}" actual
     +'
     +
      test_expect_success 'setup expected' '
    @@ t/t3701-add-interactive.sh: test_expect_success 'split hunk setup' '
     +test_expect_success 'goto hunk 1 with "g 1"' '
      	test_when_finished "git reset" &&
      	tr _ " " >expect <<-EOF &&
    - 	(2/2) Stage this hunk [y,n,q,a,d,K,g,/,e,?]? + 1:  -1,2 +1,3          +15
    + 	(2/2) Stage this hunk [y,n,q,a,d,K,g,/,e,p,?]? + 1:  -1,2 +1,3          +15
     @@ t/t3701-add-interactive.sh: test_expect_success 'goto hunk' '
      	test_cmp expect actual.trimmed
      '
    @@ t/t3701-add-interactive.sh: test_expect_success 'goto hunk' '
     +	_10
     +	+15
     +	_20
    -+	(1/2) Stage this hunk [y,n,q,a,d,j,J,g,/,e,?]?_
    ++	(1/2) Stage this hunk [y,n,q,a,d,j,J,g,/,e,p,?]?_
     +	EOF
     +	test_write_lines s y g1 | git add -p >actual &&
     +	tail -n 4 <actual >actual.trimmed &&
    @@ t/t3701-add-interactive.sh: test_expect_success 'goto hunk' '
     +test_expect_success 'navigate to hunk via regex /pattern' '
      	test_when_finished "git reset" &&
      	tr _ " " >expect <<-EOF &&
    - 	(2/2) Stage this hunk [y,n,q,a,d,K,g,/,e,?]? @@ -1,2 +1,3 @@
    + 	(2/2) Stage this hunk [y,n,q,a,d,K,g,/,e,p,?]? @@ -1,2 +1,3 @@
     @@ t/t3701-add-interactive.sh: test_expect_success 'navigate to hunk via regex' '
      	test_cmp expect actual.trimmed
      '
    @@ t/t3701-add-interactive.sh: test_expect_success 'navigate to hunk via regex' '
     +	_10
     +	+15
     +	_20
    -+	(1/2) Stage this hunk [y,n,q,a,d,j,J,g,/,e,?]?_
    ++	(1/2) Stage this hunk [y,n,q,a,d,j,J,g,/,e,p,?]?_
     +	EOF
     +	test_write_lines s y / 1,2 | git add -p >actual &&
     +	tail -n 4 <actual >actual.trimmed &&
Patrick Steinhardt· May 23, 2024, 05:31 UTC · re: Junio C Hamano · lore

Re: [PATCH v4] add-patch: enforce only one-letter response to prompts

On Wed, May 22, 2024 at 02:45:48PM -0700, Junio C Hamano wrote:
Show 31 quoted lines
> In a "git add -p" session, especially when we are not using the
> single-key mode, we may see 'qa' as a response to a prompt
> 
>   (1/2) Stage this hunk [y,n,q,a,d,j,J,g,/,e,p,?]?
> 
> and then just do the 'q' thing (i.e. quit the session), ignoring
> everything other than the first byte.
> 
> If 'q' and 'a' are next to each other on the user's keyboard, there
> is a plausible chance that we see 'qa' when the user who wanted to
> say 'a' fat-fingered and we ended up doing the 'q' thing instead.
> 
> As we didn't think of a good reason during the review discussion why
> we want to accept excess letters only to ignore them, it appears to
> be a safe change to simply reject input that is longer than just one
> byte.
> 
> The two exceptions are the 'g' command that takes a hunk number, and
> the '/' command that takes a regular expression.  They have to be
> accompanied by their operands (this makes me wonder how users who
> set the interactive.singlekey configuration feed these operands---it
> turns out that we notice there is no operand and give them another
> chance to type the operand separately, without using single key
> input this time), so we accept a string that is more than one byte
> long.
> 
> Keep the "use only the first byte, downcased" behaviour when we ask
> yes/no question, though.  Neither on Qwerty or on Dvorak, 'y' and
> 'n' are not close to each other.
> 
> Signed-off-by: Junio C Hamano <gitster@pobox.com>
This version looks good to me, thanks!
Show 24 quoted lines
> ---
>  * Hopefully the final iteration.  The differences are:
> 
>    - The end-user facing "here is what is wrong with your input"
>      message is given with err() to be consistent with other such
>      messages.
> 
>    - I gave up basing this on v2.44.0, as it is a new feature that
>      does not have to be merged down to older maintenance tracks.
>      This is now based on 80dbfac2 (Merge branch
>      'rj/add-p-typo-reaction', 2024-05-08), which is before v2.45.1
>      but has modern enough t3701 and add-patch.c:err() sends its
>      output to the standard output stream.
> 
>    - The tests for 'g' and '/' to check both the stuck and the split
>      forms have been updated for the more recent prompt that
>      includes 'p'.
> 
>    - The test for multi-key sequence expects the err() output on the
>      standard output stream.
> 
>    As an experiment, this message has the range-diff at the end, not
>    before the primary part of the patch text.  I think this format
>    should be easier to read for reviewers.

Huh, interesting. I do like that format better indeed. You did that manually instead of using `--range-diff`, right?

Patrick
Junio C Hamano· May 23, 2024, 15:58 UTC · re: Patrick Steinhardt · lore

Re: [PATCH v4] add-patch: enforce only one-letter response to prompts

Patrick Steinhardt <ps@pks.im> writes:
Show 6 quoted lines
>>    As an experiment, this message has the range-diff at the end, not
>>    before the primary part of the patch text.  I think this format
>>    should be easier to read for reviewers.
>
> Huh, interesting. I do like that format better indeed. You did that
> manually instead of using `--range-diff`, right?
Yes.

To me, "format-patch --range-diff" is a lot more cumbersome to use than running "format-patch", open the result in Emacs, and then doing "\C-u \M-! git range-diff ..." to insert its output, as I'll be opening it in the editor for typofixes anyway.

← back to recent threads