DESCRIPTION
-----------
In the first and second form, copy entries from <commit> to the index.
-In the third form, set the current branch to <commit>, optionally
-modifying index and worktree to match. The <commit> defaults to HEAD
+In the third form, set the current branch head to <commit>, optionally
+modifying index and working tree to match. The <commit> defaults to HEAD
in all forms.
'git reset' [-q] [<commit>] [--] <paths>...::
This form resets the index entries for all <paths> to their
- state at the <commit>. (It does not affect the worktree, nor
+ state at the <commit>. (It does not affect the working tree, nor
the current branch.)
+
This means that `git reset <paths>` is the opposite of `git add
linkgit:git-add[1]).
'git reset' [--<mode>] [<commit>]::
- This form points the current branch to <commit> and then
+ This form resets the current branch head to <commit> and then
updates index and working tree according to <mode>, which must
be one of the following:
+
--
--soft::
- Does not touch the index file nor the working tree at all, but
- requires them to be in a good order. This leaves all your changed
- files "Changes to be committed", as 'git status' would
- put it.
+ Does not touch the index file nor the working tree at all (but
+ resets the head to <commit>, just like all modes do). This leaves
+ all your changed files "Changes to be committed", as 'git status'
+ would put it.
--mixed::
Resets the index but not the working tree (i.e., the changed files
+
See also the --amend option to linkgit:git-commit[1].
-Undo commits permanently::
-+
-------------
-$ git commit ...
-$ git reset --hard HEAD~3 <1>
-------------
-+
-<1> The last three commits (HEAD, HEAD^, and HEAD~2) were bad
-and you do not want to ever see them again. Do *not* do this if
-you have already given these commits to somebody else. (See the
-"RECOVERING FROM UPSTREAM REBASE" section in linkgit:git-rebase[1] for
-the implications of doing so.)
-
Undo a commit, making it a topic branch::
+
------------
<2> Rewind the master branch to get rid of those three commits.
<3> Switch to "topic/wip" branch and keep working.
+Undo commits permanently::
++
+------------
+$ git commit ...
+$ git reset --hard HEAD~3 <1>
+------------
++
+<1> The last three commits (HEAD, HEAD^, and HEAD~2) were bad
+and you do not want to ever see them again. Do *not* do this if
+you have already given these commits to somebody else. (See the
+"RECOVERING FROM UPSTREAM REBASE" section in linkgit:git-rebase[1] for
+the implications of doing so.)
+
Undo a merge or pull::
+
------------
brings your index file and the working tree back to that state,
and resets the tip of the branch to that commit.
-Undo a merge or pull inside a dirty work tree::
+Undo a merge or pull inside a dirty working tree::
+
------------
$ git pull <1>
Suppose you are working on something and you commit it, and then you
continue working a bit more, but now you think that what you have in
your working tree should be in another branch that has nothing to do
-with what you commited previously. You can start a new branch and
-reset it while keeping the changes in your work tree.
+with what you committed previously. You can start a new branch and
+reset it while keeping the changes in your working tree.
+
------------
$ git tag start
file. For example, the first line of the first table means that if a
file is in state A in the working tree, in state B in the index, in
state C in HEAD and in state D in the target, then "git reset --soft
-target" will put the file in state A in the working tree, in state B
-in the index and in state D in HEAD.
+target" will leave the file in the working tree in state A and in the
+index in state B. It resets (i.e. moves) the HEAD (i.e. the tip of
+the current branch, if you are on one) to "target" (which has the file
+in state D).
working index HEAD target working index HEAD
----------------------------------------------------
--keep B C C
"reset --merge" is meant to be used when resetting out of a conflicted
-merge. Any mergy operation guarantees that the work tree file that is
+merge. Any mergy operation guarantees that the working tree file that is
involved in the merge does not have local change wrt the index before
-it starts, and that it writes the result out to the work tree. So if
+it starts, and that it writes the result out to the working tree. So if
we see some difference between the index and the target and also
-between the index and the work tree, then it means that we are not
+between the index and the working tree, then it means that we are not
resetting out from a state that a mergy operation left after failing
with a conflict. That is why we disallow --merge option in this case.