When one's only goal is to move from one commit to another, reset --keep is simply better than reset --hard, since it preserves local changes in the index and worktree when easy and errors out without doing anything when not. Update the two "how to remove commits" examples in this vein. "reset --hard" is still explained in a later example about cleaning up during a merge. Signed-off-by: Jonathan Nieder <jrnieder@xxxxxxxxx> --- Johannes Schindelin wrote: > rebase -i checks that all is well and we could come back to the current > status later if we realized that things went horribly wrong. > > reset --hard does not do that. No safety net. No reflog. Nada. Right. I think we should encourage people to use "reset --keep" more often. (In general. The particular "rebase to pull" example just mentioned is less obvious.) Documentation/git-reset.txt | 4 ++-- 1 files changed, 2 insertions(+), 2 deletions(-) diff --git a/Documentation/git-reset.txt b/Documentation/git-reset.txt index fd72976..1f13a1e 100644 --- a/Documentation/git-reset.txt +++ b/Documentation/git-reset.txt @@ -148,7 +148,7 @@ Undo a commit, making it a topic branch:: + ------------ $ git branch topic/wip <1> -$ git reset --hard HEAD~3 <2> +$ git reset --keep HEAD~3 <2> $ git checkout topic/wip <3> ------------ + @@ -163,7 +163,7 @@ Undo commits permanently:: + ------------ $ git commit ... -$ git reset --hard HEAD~3 <1> +$ git reset --keep HEAD~3 <1> ------------ + <1> The last three commits (HEAD, HEAD^, and HEAD~2) were bad -- 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