All of lore.kernel.org
 help / color / mirror / Atom feed
From: Patrick Steinhardt <ps@pks.im>
To: Junio C Hamano <gitster@pobox.com>
Cc: git@vger.kernel.org, Taylor Blau <me@ttaylorr.com>,
	Eric Sunshine <sunshine@sunshineco.com>,
	Dragan Simic <dsimic@manjaro.org>
Subject: Re: [PATCH v4] add-patch: enforce only one-letter response to prompts
Date: Thu, 23 May 2024 07:31:28 +0200	[thread overview]
Message-ID: <Zk7UsJjhY_FV2z8C@tanuki> (raw)
In-Reply-To: <xmqqh6ep1pwz.fsf_-_@gitster.g>

[-- Attachment #1: Type: text/plain, Size: 2789 bytes --]

On Wed, May 22, 2024 at 02:45:48PM -0700, Junio C Hamano wrote:
> 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!

> ---
>  * 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

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

  reply	other threads:[~2024-05-23  5:31 UTC|newest]

Thread overview: 21+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-05-21  0:37 [PATCH] add-patch: response to unknown command Rubén Justo
2024-05-21  7:03 ` Patrick Steinhardt
2024-05-21 12:59   ` Rubén Justo
2024-05-21 15:52   ` Re* " Junio C Hamano
2024-05-21 22:27     ` Taylor Blau
2024-05-21 23:06       ` Junio C Hamano
2024-05-21 23:20     ` [PATCH v2] add-patch: enforce only one-letter response to prompts Junio C Hamano
2024-05-21 23:36       ` Eric Sunshine
2024-05-22  0:49         ` Junio C Hamano
2024-05-22  6:40       ` Dragan Simic
2024-05-22 16:23         ` Junio C Hamano
2024-05-22 19:03           ` Dragan Simic
2024-05-22 20:41             ` Junio C Hamano
2024-05-22 11:07       ` Patrick Steinhardt
2024-05-22 16:27         ` Junio C Hamano
2024-05-22 17:14       ` [PATCH v3] " Junio C Hamano
2024-05-22 17:38         ` Rubén Justo
2024-05-22 19:27           ` Junio C Hamano
2024-05-22 21:45         ` [PATCH v4] " Junio C Hamano
2024-05-23  5:31           ` Patrick Steinhardt [this message]
2024-05-23 15:58             ` Junio C Hamano

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=Zk7UsJjhY_FV2z8C@tanuki \
    --to=ps@pks.im \
    --cc=dsimic@manjaro.org \
    --cc=git@vger.kernel.org \
    --cc=gitster@pobox.com \
    --cc=me@ttaylorr.com \
    --cc=sunshine@sunshineco.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.