From: Junio C Hamano <gitster@pobox.com>
Date: Sat, 20 Jun 2020 16:59:37 GMT
Subject: Re: reset --merge documentation typo?
Message-ID: <xmqqo8pdekqu.fsf@gitster.c.googlers.com>
In-Reply-To: <CANtMP6qbX_U_0sWtUvNQVtMboMLJshsHc=n-5eA4_XXNGEnzLQ@mail.gmail.com>

Solomon Ucko <solly.ucko@gmail.com> 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.