On Tue, Dec 30, 2025 at 12:23 AM Junio C Hamano [off-list ref] wrote:

"D. Ben Knoble" [off-list ref] writes:

quoted

 `git reset (--patch | -p) [<tree-ish>] [--] [<pathspec>...]`::
-     Interactively select hunks in the difference between the index
-     and _<tree-ish>_ (defaults to `HEAD`).  The chosen hunks are applied
-     in reverse to the index.
+     Interactively select changes from the difference between the index
+     and the specified commit or tree (which defaults to `HEAD`).
+     The chosen changes are added to the index.

The previous iteration said "changes are unstaged", implying that
the changes are removed from the index.  But now it says the changes
are added to the index.  Which one?

Ah, I think I really mean that _changes_ are added. The change might
be an addition (+) or subtraction (-) in patch terms, so some changes
may result in the index having fewer modifications relative to the
working tree or something. But it's not
very clear, and certainly a bit pedantic.

I think neither is correct.  I wasn't involved in the design of the
behaviour of "reset -p", but IIUC,

    git reset -p
    git reset -p HEAD

show "git diff --cached HEAD" (i.e., what damage you will cause if
you commit what is in the index), so chosen hunks will be reverted
out of the index if you say "y" to "reset -p" prompt.

Indeed. I was actually expecting to see the reverse hunks here, so I
was surprised to see the staged hunks.

On the other hand,

    git reset -p COMMIT

for COMMIT that is not HEAD gives "git diff -R --cached COMMIT"
(i.e., the changes to take you closer to the named commit), so
chosen hunks will participate in the next commit if you commit after
completing this "reset -p" session.

Hm. I can see how this behaves nearly the opposite of the former. Yikes.

    The contents in the index are modified using the chosen hunks.

is the best description I can come up with.

The actual prompt asks "unstage this hunk?" when operating against
HEAD, while the prompt changes to "apply this hunk to index?" when
opeating against a commit that is not HEAD, so it might be simpler
not to say anything about the direction of the application (i.e.,
how the chosen hunks are used to modify the index) in this
paragraph, like the above example, may be a viable option.

Yeah, I think so. Will send a new version with this update.