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@xxxxxxxxx> --- Joshua Jensen wrote: > I've always wished "git reset --hard" would tell me there are > modified files and force me to type "git reset --hard --force" to > overwrite them. It is a dangerous command, and I stupidly run it > sometimes without running "git status" first. Have you tried "git reset --keep"? How does it compare to your wish? Documentation/git-reset.txt | 9 ++------- 1 files changed, 2 insertions(+), 7 deletions(-) diff --git a/Documentation/git-reset.txt b/Documentation/git-reset.txt index fd72976..927ecee 100644 --- a/Documentation/git-reset.txt +++ b/Documentation/git-reset.txt @@ -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, -- 1.7.4.rc2 -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html