Hi Junio,
On 06/03/2018 22:03, Junio C Hamano wrote:
>
> > A small nitpick - I see you use phrasing like "select lines", where
> > the other commands usually talk about "staging", instead, so "stage
> > lines" might be more aligned with the existing text.
>
> Isn't this machinery shared across "add -p" and "reset -p"? What is
> done to the selected lines when you are using this UI while running
> "reset -p"? I hope it is not "staging". If the interface only
> "selects lines" and what is done to the selected lines depends on
> what operation is using this backend, then the current phrasing is
> perfectly fine and saying "staging" makes it actively worse.
Hmm, if that is the case, I agree, but I was merely trying to review
the files being changed - for example, inside "Documentation/git-add.txt":
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
g - select a hunk to go to
/ - search for a hunk matching the given regex
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
s - split the current hunk into smaller hunks
e - manually edit the current hunk
? - print help
In there, adding "l" should follow "stage" phrasing, I would think.
But you are right for "git-add--interactive.perl", for example - in
there, I didn`t notice the line (seems to be?) added inside the shared
"help_patch_cmd".
But if so, I guess it should then be moved to more context-related
"help_patch_modes", being phrased accordingly in there.
Thanks for pointing this out, let me recheck my comments.
Regards, Buga
