Documentation: reset: add some missing tables
and while at it also explain why --merge option is disallowed in some cases. Signed-off-by: Christian Couder <chriscool@tuxfamily.org> Signed-off-by: Junio C Hamano <gitster@pobox.com>
This commit is contained in:
parent
bf96c93199
commit
397d596f84
@ -79,6 +79,13 @@ git reset --option target
|
||||
to reset the HEAD to another commit (`target`) with the different
|
||||
reset options depending on the state of the files.
|
||||
|
||||
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.
|
||||
|
||||
working index HEAD target working index HEAD
|
||||
----------------------------------------------------
|
||||
A B C D --soft A B D
|
||||
@ -107,12 +114,28 @@ reset options depending on the state of the files.
|
||||
--hard C C C
|
||||
--merge C C C
|
||||
|
||||
In these tables, A, B, C and D are some different states of a
|
||||
file. For example, the last line of the last table means that if a
|
||||
file is in state B in the working tree and the index, and in a
|
||||
different state C in HEAD and in the target, then "git reset
|
||||
--merge target" will put the file in state C in the working tree,
|
||||
in the index and in HEAD.
|
||||
working index HEAD target working index HEAD
|
||||
----------------------------------------------------
|
||||
B C C D --soft B C D
|
||||
--mixed B D D
|
||||
--hard D D D
|
||||
--merge (disallowed)
|
||||
|
||||
working index HEAD target working index HEAD
|
||||
----------------------------------------------------
|
||||
B C C C --soft B C C
|
||||
--mixed B C C
|
||||
--hard C C C
|
||||
--merge 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
|
||||
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
|
||||
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
|
||||
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.
|
||||
|
||||
The following tables show what happens when there are unmerged
|
||||
entries:
|
||||
|
Loading…
Reference in New Issue
Block a user