mirror of
https://github.com/git/git.git
synced 2024-11-02 15:28:21 +01:00
Merge branch 'mg/reset-doc'
* mg/reset-doc: git-reset.txt: make modes description more consistent git-reset.txt: point to git-checkout git-reset.txt: use "working tree" consistently git-reset.txt: reset --soft is not a no-op git-reset.txt: reset does not change files in target git-reset.txt: clarify branch vs. branch head
This commit is contained in:
Junio C Hamano
commit
a6fa2a87b7
1 changed files with 47 additions and 29 deletions
|
|
@ -15,17 +15,24 @@ SYNOPSIS
|
|||
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 (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 <commit>. (It does not affect the working tree, nor
|
||||
the current branch.)
|
||||
+
|
||||
This means that `git reset <paths>` is the opposite of `git add
|
||||
<paths>`.
|
||||
+
|
||||
After running `git reset <paths>` to update the index entry, you can
|
||||
use linkgit:git-checkout[1] to check the contents out of the index to
|
||||
the working tree.
|
||||
Alternatively, using linkgit:git-checkout[1] and specifying a commit, you
|
||||
can copy the contents of a path out of a commit to the index and to the
|
||||
working tree in one go.
|
||||
|
||||
'git reset' --patch|-p [<commit>] [--] [<paths>...]::
|
||||
Interactively select hunks in the difference between the index
|
||||
|
|
@ -36,16 +43,17 @@ This means that `git reset -p` is the opposite of `git add -p` (see
|
|||
linkgit:git-add[1]).
|
||||
|
||||
'git reset' [--<mode>] [<commit>]::
|
||||
This form points the current branch to <commit> and then
|
||||
updates index and working tree according to <mode>, which must
|
||||
be one of the following:
|
||||
This form resets the current branch head to <commit> and
|
||||
possibly updates the index (resetting it to the tree of <commit>) and
|
||||
the working tree depending on <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
|
||||
|
|
@ -53,22 +61,30 @@ linkgit:git-add[1]).
|
|||
been updated. This is the default action.
|
||||
|
||||
--hard::
|
||||
Matches the working tree and index to that of the tree being
|
||||
switched to. Any changes to tracked files in the working tree
|
||||
since <commit> are lost.
|
||||
Resets the index and working tree. Any changes to tracked files in the
|
||||
working tree since <commit> are discarded.
|
||||
|
||||
--merge::
|
||||
Resets the index to match the tree recorded by the named commit,
|
||||
and updates the files that are different between the named commit
|
||||
and the current commit in the working tree.
|
||||
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).
|
||||
If a file that is different between <commit> and the index has unstaged
|
||||
changes, reset is aborted.
|
||||
+
|
||||
In other words, --merge does something like a 'git read-tree -u -m <commit>',
|
||||
but carries forward unmerged index entries.
|
||||
|
||||
--keep::
|
||||
Reset the index to the given commit, keeping local changes in
|
||||
the working tree since the current commit, while updating
|
||||
working tree files without local changes to what appears in
|
||||
the given commit. If a file that is different between the
|
||||
current commit and the given commit has local changes, reset
|
||||
is aborted.
|
||||
Resets the index, updates files in the working tree that are
|
||||
different between <commit> and HEAD, but keeps those
|
||||
which are different between HEAD and the working tree (i.e.
|
||||
which have local changes).
|
||||
If a file that is different between <commit> and HEAD has local changes,
|
||||
reset is aborted.
|
||||
+
|
||||
In other words, --keep does a 2-way merge between <commit> and HEAD followed by
|
||||
'git reset --mixed <commit>'.
|
||||
--
|
||||
|
||||
If you want to undo a commit other than the latest on a branch,
|
||||
|
|
@ -184,7 +200,7 @@ tip of the current branch in ORIG_HEAD, so resetting hard to it
|
|||
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>
|
||||
|
|
@ -257,7 +273,7 @@ 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 committed previously. You can start a new branch and
|
||||
reset it while keeping the changes in your work tree.
|
||||
reset it while keeping the changes in your working tree.
|
||||
+
|
||||
------------
|
||||
$ git tag start
|
||||
|
|
@ -294,8 +310,10 @@ In these tables, A, B, C and D are some different states of a
|
|||
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
|
||||
----------------------------------------------------
|
||||
|
|
@ -346,11 +364,11 @@ in the index and in state D in 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.
|
||||
|
||||
|
|
|
|||
Loading…
Reference in a new issue