Solomon Ucko <solly.ucko@xxxxxxxxx> writes:
> Oops, accidentally sent as HTML instead of plain text.
>
> The documentation for `git reset --merge` states:
It is talknig about `git reset --merge <commit>`.
>> Resets the index and updates the files in the working tree that are
>> different between `<commit>` and `HEAD`, but keeps those which are
>> different between the index and working tree (i.e. which have changes
>> which have not been added).
Correct. The command makes this request to "git".
I am on the commit at `HEAD`; I want to move to <commit> as if I
did "git checkout <otherbranch>", updating the files in the
working tree to that of <otherbranch> except that if I had local
changes from `HEAD` for a path, and the path is identical
between `HEAD` and <otherbranch>, carry my local changes along,
but I am not flipping to a different branch---instead I am
resetting the tip of the current branch.
It allows the user to pretend as if the user started making these
local changes _after_ "git reset --hard <commit>", on top of
<commit>, and that is only possible because the command makes sure
that the paths involved in these local changes are the same between
`HEAD` and <commit>.
> Where it says "`HEAD`", should it say "the index"?
No.
