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