Fix double definitions of xrefs

Author: jnavila

C-git-commands.asc

@@ -205,7 +205,7 @@ We use it to reintroduce file conflicts with `--conflict=diff3` in <<ch07-git-to
 
 We go into closer detail on its relationship with `git reset` in <<ch07-git-tools#_git_reset>>.
 
-Finally, we go into some implementation detail in <<ch10-git-internals#_the_head>>.
+Finally, we go into some implementation detail in <<ch10-git-internals#ref_the_ref>>.
 
 ==== git merge
 
@@ -417,7 +417,7 @@ Rebasing is covered in detail in <<ch03-git-branching#_rebasing>>, including cov
 
 We use it in practice during an example of splitting your history into two separate repositories in <<ch07-git-tools#_replace>>, using the `--onto` flag as well.
 
-We go through running into a merge conflict during rebasing in <<ch07-git-tools#_rerere>>.
+We go through running into a merge conflict during rebasing in <<ch07-git-tools#ref_rerere>>.
 
 We also use it in an interactive scripting mode with the `-i` option in <<ch07-git-tools#_changing_multiple>>.
 
@@ -533,7 +533,7 @@ There were also quite a number of lower level plumbing commands that we encounte
 
 The first one we encounter is `ls-remote` in <<ch06-github#_pr_refs>> which we use to look at the raw references on the server.
 
-We use `ls-files` in <<ch07-git-tools#_manual_remerge>>, <<ch07-git-tools#_rerere>> and <<ch07-git-tools#_the_index>> to take a more raw look at what your staging area looks like.
+We use `ls-files` in <<ch07-git-tools#_manual_remerge>>, <<ch07-git-tools#ref_rerere>> and <<ch07-git-tools#_the_index>> to take a more raw look at what your staging area looks like.
 
 We also mention `rev-parse` in <<ch07-git-tools#_branch_references>> to take just about any string and turn it into an object SHA-1.
 

book/05-distributed-git/sections/maintaining.asc

@@ -422,7 +422,7 @@ Now, whenever you do a merge that resolves conflicts, the resolution will be rec
 If you need to, you can interact with the rerere cache using the `git rerere` command.
 When it's invoked alone, Git checks its database of resolutions and tries to find a match with any current merge conflicts and resolve them (although this is done automatically if `rerere.enabled` is set to `true`).
 There are also subcommands to see what will be recorded, to erase specific resolution from the cache, and to clear the entire cache.
-We will cover rerere in more detail in <<ch07-git-tools#_rerere>>.
+We will cover rerere in more detail in <<ch07-git-tools#ref_rerere>>.
 
 [[_tagging_releases]]
 ==== Tagging Your Releases

book/07-git-tools/sections/rerere.asc

@@ -1,4 +1,4 @@
-[[_rerere]]
+[[ref_rerere]]
 === Rerere
 
 The `git rerere` functionality is a bit of a hidden feature.

book/10-git-internals/sections/refs.asc

@@ -64,7 +64,7 @@ image::images/data-model-4.png[Git directory objects with branch head references
 
 When you run commands like `git branch <branch>`, Git basically runs that `update-ref` command to add the SHA-1 of the last commit of the branch you're on into whatever new reference you want to create.
 
-[[_the_head]]
+[[ref_the_ref]]
 ==== The HEAD
 
 The question now is, when you run `git branch <branch>`, how does Git know the SHA-1 of the last commit?