fix all the xrefs I could find

Author: schacon

book/01-introduction/sections/first-time-setup.asc

@@ -1,3 +1,4 @@
+[[_first_time]]
 === First-Time Git Setup
 
 Now that you have Git on your system, you'll want to do a few things to customize your Git environment.

book/03-git-branching/sections/basic-branching-and-merging.asc

@@ -141,6 +141,7 @@ image::images/basic-branching-6.png[Work continues on `iss53`.]
 It's worth noting here that the work you did in your `hotfix` branch is not contained in the files in your `iss53` branch.
 If you need to pull it in, you can merge your `master` branch into your `iss53` branch by running `git merge master`, or you can wait to integrate those changes until you decide to pull the `iss53` branch back into `master` later.
 
+[[_basic_merging]]
 ==== Basic Merging
 
 (((branches, merging)))(((merging)))

book/04-git-server/sections/git-on-a-server.asc

@@ -1,4 +1,4 @@
-[[_git_on_server]]
+[[_git_on_the_server]]
 === Getting Git on a Server
 
 Now we'll cover setting up a Git service running these protocols on your own server.

book/04-git-server/sections/protocols.asc

@@ -46,7 +46,7 @@ Then, you can push to and pull from that remote as though you were doing so over
 The pros of file-based repositories are that they're simple and they use existing file permissions and network access.
 If you already have a shared filesystem to which your whole team has access, setting up a repository is very easy.
 You stick the bare repository copy somewhere everyone has shared access to and set the read/write permissions as you would for any other shared directory.
-We'll discuss how to export a bare repository copy for this purpose in <<_getting_git_on_a_server>>.
+We'll discuss how to export a bare repository copy for this purpose in <<_git_on_the_server>>.
 
 This is also a nice option for quickly grabbing work from someone else's working repository.
 If you and a co-worker are working on the same project and they want you to check something out, running a command like `git pull /home/john/project` is often easier than them pushing to a remote server and you pulling down.

book/06-github/1-github.asc

@@ -1,3 +1,4 @@
+[[_github]]
 == GitHub
 
 (((GitHub)))

book/08-customizing-git/sections/config.asc

@@ -489,4 +489,4 @@ $ git config --system receive.denyDeletes true
 
 This denies any deletion of branches or tags – no user can do it.
 To remove remote branches, you must remove the ref files from the server manually.
-There are also more interesting ways to do this on a per-user basis via ACLs, as you'll learn in <<_enforcing_a_user_based_acl_system>>.
+There are also more interesting ways to do this on a per-user basis via ACLs, as you'll learn in <<_an_example_git_enforced_policy>>.

book/08-customizing-git/sections/hooks.asc

@@ -1,4 +1,4 @@
-[[_hooks]]
+[[_git_hooks]]
 === Git Hooks
 
 (((hooks)))
@@ -27,7 +27,7 @@ This section splits them into committing-workflow hooks, e-mail-workflow scripts
 [NOTE]
 ====
 It's important to note that client-side hooks are *not* copied when you clone a repository.
-If your intent with these scripts is to enforce a policy, you'll probably want to do that on the server side; see the example in <<_example_policy>>.
+If your intent with these scripts is to enforce a policy, you'll probably want to do that on the server side; see the example in <<_an_example_git_enforced_policy>>.
 ====
 
 ===== Committing-Workflow Hooks

book/10-git-internals/sections/plumbing-porcelain.asc

@@ -29,7 +29,7 @@ refs/
 You may see some other files in there, but this is a fresh `git init` repository – it's what you see by default.
 The `description` file is only used by the GitWeb program, so don't worry about it.
 The `config` file contains your project-specific configuration options, and the `info` directory keeps a global exclude file (((excludes))) for ignored patterns that you don't want to track in a .gitignore file.
-The `hooks` directory contains your client- or server-side hook scripts, which are discussed in detail in <<_hooks>>.
+The `hooks` directory contains your client- or server-side hook scripts, which are discussed in detail in <<_git_hooks>>.
 
 This leaves four important entries: the `HEAD` and (yet to be created) `index` files, and the `objects` and `refs` directories.
 These are the core parts of Git.

book/C-git-commands/1-git-commands.asc

@@ -17,7 +17,7 @@ The `git config` command has been used in nearly every chapter of the book.
 
 In <<_first_time>> we used it to specify our name, email address and editor preference before we even got started using Git.
 
-In <<_aliases>> we showed how you could use it to create shorthand commands that expand to long option sequences so you don't have to type them every time.
+In <<_git_aliases>> we showed how you could use it to create shorthand commands that expand to long option sequences so you don't have to type them every time.
 
 In <<_rebasing>> we used it to make `--rebase` the default when you run `git pull`.
 
@@ -57,7 +57,7 @@ The `git clone` command is used in dozens of places throughout the book, but we'
 
 It's basically introduced and explained in <<_git_cloning>>, where we go through a few examples.
 
-In <<_git_on_server>> we look at using the `--bare` option to create a copy of a Git repository with no working directory.
+In <<_git_on_the_server>> we look at using the `--bare` option to create a copy of a Git repository with no working directory.
 
 In <<_bundling>> we use it to unbundle a bundled Git repository.