Documentation: do not treat reset --keep as a special case
The current treatment of "git reset --keep" emphasizes how it differs from --hard (treatment of local changes) and how it breaks down into plumbing (git read-tree -m -u HEAD <commit> followed by git update-ref HEAD <commit>). This can discourage people from using it, since it might seem to be a complex or niche option. Better to emphasize what the --keep flag is intended for --- moving the index and worktree from one commit to another, like "git checkout" would --- so the reader can make a more informed decision about the appropriate situations in which to use it. Signed-off-by: Jonathan Nieder <jrnieder@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
Jonathan Nieder committed
Jan 21, 2011 at 12:37 UTC
8c0db6fd51cec5fd82cf4054818c0a1ca4a58f37
1 file changed
+2
-7
Documentation/git-reset.txt
+2
-7
@@ -76,15 +76,10 @@ In other words, --merge does something like a 'git read-tree -u -m <commit>',
76
but carries forward unmerged index entries.
77
78
--keep::
79
- Resets the index, updates files in the working tree that are
80
- different between <commit> and HEAD, but keeps those
81
- which are different between HEAD and the working tree (i.e.
82
- which have local changes).
79
+ Resets index entries and updates files in the working tree that are
80
+ different between <commit> and HEAD.
81
If a file that is different between <commit> and HEAD has local changes,
82
reset is aborted.
85
-+
86
-In other words, --keep does a 2-way merge between <commit> and HEAD followed by
87
-'git reset --mixed <commit>'.
83
--
84
85
If you want to undo a commit other than the latest on a branch,