Thread (2 messages) 2 messages, 2 authors, 2025-12-01

Re: [PATCH] add -p: show hunk selection state when selecting hunks

From: Abraham Samuel Adekunle <hidden>
Date: 2025-12-01 10:01:37

On Sun, Nov 30, 2025 at 10:32:56AM -0800, Junio C Hamano wrote:
Abraham Samuel Adekunle [off-list ref] writes:
quoted
diff --git a/add-patch.c b/add-patch.c
index 173a53241e..e70e390506 100644
--- a/add-patch.c
+++ b/add-patch.c
@@ -45,7 +45,7 @@ static struct patch_mode patch_mode_add = {
 		N_("Stage mode change [y,n,q,a,d%s,?]? "),
 		N_("Stage deletion [y,n,q,a,d%s,?]? "),
 		N_("Stage addition [y,n,q,a,d%s,?]? "),
-		N_("Stage this hunk [y,n,q,a,d%s,?]? ")
+		N_("Stage this hunk [y,n,q,a,d%s,?] %s? ")
 	},
Three comments:

 * These sets of prompts exist for each front-end that uses the
   interactive patch machinery, and we are looking at the set used
   by "git add -p".  But the "I came back here with K, or I do not
   remember which between k and K I came back here with, and I
   cannot easily tell if the hunk I am looking at is already
   selected" issue is shared with other users like "git reset -p".
Hello Junio,
Thank you for your review.

Okay, are you suggesting I apply the tweak in all prompt_mode arrays
used by other front-ends. I can see all the others modes (patch_mode_*)
shown in the file.
 * "chmod +x Makefile && echo >>Makefile && git add -p" would ask if
   you want to stage the mode change of the path and content change
   for the path separately.  You may skip, and later come back with
   K to this question.  The same "hmph, have I selected to use
   this?" issue exists, no?
Yes true, the issue does exist.
I will fix the change for the others
 * The existing "[choices]? " was designed to be at the very end of
   the question, so that the answer given by the user will come
   immediately after the offered choices.  Adding an overly long
   "selected" or "deselected" to make it "[choices] selected?" does
   not give us a pleasant end-user experience.
Okay.
Also, after you decided on one hunk when you have two hunks, typing
'j' or 'k' would tell you "No other undecided hunk".  The phrase
used here, "undecided", refers to the choice between USE or SKIP.
To convey the intent clearly, "Select"/"Deselect" feels a rather
indirect way (i.e. "selected for use" vs "selected to skip") to say
what is happening.

Ideally, if we can convey

    Stage this mode change (you previously decided to use it) [y,n,q,a,d%s,?]?
    Stage this mode change (you previously decided to skip it) [y,n,q,a,d%s,?]?
    Stage this deletion (you previously decided to use it) [y,n,q,a,d%sm,?]?
    ...

without wasting too many extra display width, that would be great,
Okay this makes sense. But since the display width is something to watch out for,
would something like below siffice?

	Stage this mode change (previous decision: stage) [y,n,q,a,d%s,?]?
	Stage this mode change (previous decision: skip) [y,n,q,a,d%s,?]?
	Stage this deletion (previous decision: stage) [y,n,q,a,d%s,?]?
but this patch is not quite there, I am afraid to say.
Thank you Junio, I will work towards getting it there.
[...]

Abraham
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help