From: Junio C Hamano <gitster@pobox.com>
To: Phillip Wood <phillip.wood123@gmail.com>
Cc: "Rubén Justo" <rjusto@gmail.com>,
"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 08:22:52 -0700 [thread overview]
Message-ID: <xmqqr0f5fi2b.fsf@gitster.g> (raw)
In-Reply-To: <64d4ba8e-0dfe-407c-9b32-d02f1ce40393@gmail.com> (Phillip Wood's message of "Tue, 16 Apr 2024 14:56:37 +0100")
Phillip Wood <phillip.wood123@gmail.com> writes:
>> 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).
>
> The complete list of help is 15 lines long (we don't always print
> everything but if you're in the middle of staging several hunks from
> the same file we do)
Ah, OK. Even though I was the one who stole this feature from
elsewhere, I forgot that we had that many commands, and it makes the
decision a lot simpler ;-)
> y - stage this hunk
> n - do not stage this hunk
> q - quit; do not stage this hunk or any of the remaining ones
> a - stage this hunk and all later hunks in the file
> d - do not stage this hunk or any of the later hunks in the file
> j - leave this hunk undecided, see next undecided hunk
> J - leave this hunk undecided, see next hunk
> k - leave this hunk undecided, see previous undecided hunk
> K - leave this hunk undecided, see previous hunk
> g - select a hunk to go to
> / - search for a hunk matching the given regex
> s - split the current hunk into smaller hunks
> e - manually edit the current hunk
> p - print the current hunk
> ? - print help
>
> I find it long enough to be annoying as it means there is a
> significant distance between the prompt and the hunk text.
Yes, I now agree.
So the log message may want a bit of rewrite in the title and the
introductory part, with a clarification that '?' is what we already
had and not what this adds (from Patrick's comment), and there may
be other small improvements we want to see that I may have missed,
but other than these small-ish points, the basic direction of this
patch is good?
This is a tangent, but I think we _mostly_ take these commands case
insensitively (e.g., you can say 'Q' to quit the program, as well as
'q' that is listed above). But 'k' and 'j' (there may be others)
act differently when given in the uppercase. This would limit our
ability to later add capitalized variant of an already used lower
case letter without retraining users---should we find it disturbing,
or is "add -p" mostly done and we do not have to worry?
Thanks.
next prev parent reply other threads:[~2024-04-16 15:22 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
2024-04-16 13:56 ` Phillip Wood
2024-04-16 15:22 ` Junio C Hamano [this message]
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=xmqqr0f5fi2b.fsf@gitster.g \
--to=gitster@pobox.com \
--cc=git@vger.kernel.org \
--cc=phillip.wood123@gmail.com \
--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.