Browse Source

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>
maint
Jonathan Nieder 14 years ago committed by Junio C Hamano
parent
commit
8c0db6fd51
  1. 9
      Documentation/git-reset.txt

9
Documentation/git-reset.txt

@ -76,15 +76,10 @@ In other words, --merge does something like a 'git read-tree -u -m <commit>', @@ -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,

Loading…
Cancel
Save