fix _git_tools links

Author: schacon

book/02-git-basics/sections/undoing.asc

@@ -82,7 +82,7 @@ The `benchmarks.rb` file is modified but once again unstaged.
 While `git reset` _can_ be a dangerous command if you call it with `--hard`, in this instance the file in your working directory is not touched. Calling `git reset` without an option is not dangerous - it only touches your staging area.
 =====
 
-For now this magic invocation is all you need to know about the `git reset` command. We'll go into much more detail about what `reset` does and how to master it to do really interesting things in <<_git_tools_reset>>.
+For now this magic invocation is all you need to know about the `git reset` command. We'll go into much more detail about what `reset` does and how to master it to do really interesting things in <<_reset>>.
 
 ==== Unmodifying a Modified File
 

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

@@ -268,7 +268,6 @@ Hit return to start merge resolution tool (opendiff):
 
 If you want to use a merge tool other than the default (Git chose `opendiff` in this case because the command was run on a Mac), you can see all the supported tools listed at the top after ``one of the following tools.''
 Just type the name of the tool you'd rather use.
-In <<_git_tools>>, we'll discuss how you can change this default value for your environment (Git gave us a helpful hint).
 
 If you need more advanced tools for resolving tricky merge conflicts, we cover more on merging in <<_advanced_merging>>.
 

book/03-git-branching/sections/remote-branches.asc

@@ -185,7 +185,7 @@ It will simply get the data for you and let you merge it yourself.
 However, there is a command called `git pull` which is essentially a `git fetch` immediately followed by a `git merge` in most cases.
 If you have a tracking branch set up as demonstrated in the last section, either by explicitly setting it or by having it created for you by the `clone` or `checkout` commands, `git pull` will look up what server and branch your current branch is tracking, fetch from that server and then try to merge in that remote branch.
 
-There are other uses of the `pull` command that we'll address in [[_git_tools]], but generally it's better to simply use the `fetch` and `merge` commands explicitly as  the magic of `git pull` can often be confusing.
+Generally it's better to simply use the `fetch` and `merge` commands explicitly as the magic of `git pull` can often be confusing.
 
 ==== Deleting Remote Branches
 

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

@@ -50,7 +50,7 @@ Even if you don't commit during the weekend, use the staging area on Monday to s
 If some of the changes modify the same file, try to use `git add --patch` to partially stage files (covered in detail in <<_staging_patches>>).
 The project snapshot at the tip of the branch is identical whether you do one commit or five, as long as all the changes are added at some point, so try to make things easier on your fellow developers when they have to review your changes.
 This approach also makes it easier to pull out or revert one of the changesets if you need to later.
-<<_git_tools>> describes a number of useful Git tricks for rewriting history and interactively staging files – use these tools to help craft a clean and understandable history.
+<<_rewriting_history>> describes a number of useful Git tricks for rewriting history and interactively staging files – use these tools to help craft a clean and understandable history.
 
 The last thing to keep in mind is the commit message.
 Getting in the habit of creating quality commit messages makes using and collaborating with Git a lot easier.
@@ -493,7 +493,7 @@ $ git commit
 $ git commit
 -----
 
-You may want to use `rebase -i` to squash your work down to a single commit, or rearrange the work in the commits to make the patch easier for the maintainer to review – see <<_git_tools>> for more information about interactive rebasing.
+You may want to use `rebase -i` to squash your work down to a single commit, or rearrange the work in the commits to make the patch easier for the maintainer to review – see <<_rewriting_history>> for more information about interactive rebasing.
 
 When your branch work is finished and you're ready to contribute it back to the maintainers, go to the original project page and click the ``Fork'' button, creating your own writable fork of the project.
 You then need to add in this new repository URL as a second remote, in this case named `myfork`:

book/06-github/1-github.asc

@@ -8,7 +8,7 @@ So while it's not a direct part of the Git open source project, there's a good c
 This chapter is about using GitHub effectively.
 We'll cover signing up for and managing an account, creating and using Git repositories, common workflows, interacting with projects, lots of little tips to make your life easier, and GitHub's programmatic interface.
 
-If you are not interested in using GitHub to host your own projects or to collaborate with other projects that are hosted on GitHub, you can safely skip to the <<_git_tools, next chapter>>.
+If you are not interested in using GitHub to host your own projects or to collaborate with other projects that are hosted on GitHub, you can safely skip to <<_git_tools>>.
 
 include::sections/setting-up-account.asc[]
 

book/07-git-tools/1-git-tools.asc

@@ -1,3 +1,4 @@
+[[_git_tools]]
 == Git Tools
 
 By now, you’ve learned most of the day-to-day commands and workflows that you need to manage or maintain a Git repository for your source code control.

book/07-git-tools/sections/rewriting-history.asc

@@ -1,3 +1,4 @@
+[[_rewriting_history]]
 === Rewriting History
 
 Many times, when working with Git, you may want to revise your commit history for some reason.

book/11-git-internals/sections/maintenance.asc

@@ -275,7 +275,7 @@ da3f30d019005479c99eb4c3406225613985a1db oops - removed large tarball
 ----
 
 You must rewrite all the commits downstream from `6df76` to fully remove this file from your Git history.
-To do so, you use `filter-branch`, which you used in <<_git_tools>>:
+To do so, you use `filter-branch`, which you used in <<_rewriting_history>>:
 
 [source,shell]
 ----
@@ -286,7 +286,7 @@ Rewrite da3f30d019005479c99eb4c3406225613985a1db (2/2)
 Ref 'refs/heads/master' was rewritten
 ----
 
-The `--index-filter` option is similar to the `--tree-filter` option used in <<_git_tools>>, except that instead of passing a command that modifies files checked out on disk, you’re modifying your staging area or index each time.
+The `--index-filter` option is similar to the `--tree-filter` option used in <<_rewriting_history>>, except that instead of passing a command that modifies files checked out on disk, you’re modifying your staging area or index each time.
 Rather than remove a specific file with something like `rm file`, you have to remove it with `git rm --cached` – you must remove it from the index, not from disk.
 The reason to do it this way is speed – because Git doesn’t have to check out each revision to disk before running your filter, the process can be much, much faster.
 You can accomplish the same task with `--tree-filter` if you want.