git-reset.txt: use "working tree" consistently
as per git help glossary Signed-off-by: Michael J Gruber <git@drmicha.warpmail.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
This commit is contained in:
parent
cca5d0b04a
commit
06cdac5ab6
@ -16,12 +16,12 @@ DESCRIPTION
|
||||
-----------
|
||||
In the first and second form, copy entries from <commit> to the index.
|
||||
In the third form, set the current branch head to <commit>, optionally
|
||||
modifying index and worktree to match. The <commit> defaults to HEAD
|
||||
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
|
||||
@ -184,7 +184,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 +257,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
|
||||
@ -348,11 +348,11 @@ in state D).
|
||||
--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 New Issue
Block a user