Code

Documentation: do not treat reset --keep as a special case
authorJonathan Nieder <jrnieder@gmail.com>
Fri, 21 Jan 2011 18:37:34 +0000 (12:37 -0600)
committerJunio C Hamano <gitster@pobox.com>
Fri, 21 Jan 2011 20:41:14 +0000 (12:41 -0800)
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>
Documentation/git-reset.txt

index fd72976371cee0fcd25e3419138eb13382dc6ab8..927ecee2f26cdf0bd30457d5016b654c01a23a14 100644 (file)
@@ -76,15 +76,10 @@ In other words, --merge does something like a 'git read-tree -u -m <commit>',
 but carries forward unmerged index entries.
 
 --keep::
-       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).
+       Resets index entries and updates files in the working tree that are
+       different between <commit> and HEAD.
        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,