this just is not true

Author: schacon

book/07-git-tools/sections/advanced-merging.asc

@@ -493,10 +493,10 @@ There are two ways to approach this problem, depending on what your desired outc
 ===== Fix the references
 
 If the unwanted merge commit only exists on your local repository, the easiest and best solution is to move the branches so that they point where you want them to.
-In most cases, if you follow the errant `git merge` with `git merge --abort`, this will reset the branch pointers so they look like this:
+In most cases, if you follow the errant `git merge` with `git reset --hard HEAD~`, this will reset the branch pointers so they look like this:
 
-.History after `git merge --abort`
-image::images/undomerge-reset.png[History after `git reset --merge`.]
+.History after `git reset --hard HEAD~`
+image::images/undomerge-reset.png[History after `git reset --hard HEAD~`.]
 
 We covered `reset` back in <<_git_reset>>, so it shouldn't be too hard to figure out what's going on here.
 Here's a quick refresher: `reset --hard` usually goes through three steps:
@@ -506,8 +506,6 @@ Here's a quick refresher: `reset --hard` usually goes through three steps:
 . Make the index look like HEAD.
 . Make the working directory look like the index.
 
-In the case of `git merge --abort`, Git is actually running a `git reset --merge` and when doing so, Git is extra careful with steps 2 and 3 to preserve any changes you've made in the working directory or the index, but otherwise works as though this were a `--hard` reset.
-
 The downside of this approach is that it's rewriting history, which can be problematic with a shared repository.
 Check out <<_rebase_peril>> for more on what can happen; the short version is that if other people have the commits you're rewriting, you should probably avoid `reset`.
 This approach also won't work if any other commits have been created since the merge; moving the refs would effectively lose those changes.