change name of chapters to adapt to git-scm scripts

Author: jnavila

_git_in_other_environments.asc renamed to A-git-in-other-environments.asc

@@ -1,4 +1,4 @@
-[[_git_in_other_environments]]
+[[A-git-in-other-environments]]
 [appendix]
 == Git in Other Environments
 

_embedding_git_in_your_applications.asc renamed to B-embedding-git-in-your-applications.asc

@@ -1,4 +1,4 @@
-[[_embedding_git_in_your_applications]]
+[[B-embedding-git-in-your-applications]]
 [appendix]
 == Embedding Git in your Applications
 

_git_commands.asc renamed to C-git-commands.asc

@@ -26,7 +26,7 @@ image::images/snapshots.png[Git stores data as snapshots of the project over tim
 This is an important distinction between Git and nearly all other VCSs.
 It makes Git reconsider almost every aspect of version control that most other systems copied from the previous generation.
 This makes Git more like a mini filesystem with some incredibly powerful tools built on top of it, rather than simply a VCS.
-We'll explore some of the benefits you gain by thinking of your data this way when we cover Git branching in <<_git_branching#_git_branching>>.
+We'll explore some of the benefits you gain by thinking of your data this way when we cover Git branching in <<ch03-git-branching#ch03-git-branching>>.
 
 ==== Nearly Every Operation Is Local
 
@@ -71,7 +71,7 @@ It is hard to get the system to do anything that is not undoable or to make it e
 As with any VCS, you can lose or mess up changes you haven't committed yet, but after you commit a snapshot into Git, it is very difficult to lose, especially if you regularly push your database to another repository.
 
 This makes using Git a joy because we know we can experiment without the danger of severely screwing things up.
-For a more in-depth look at how Git stores its data and how you can recover data that seems lost, see <<_git_basics_chapter#_undoing>>.
+For a more in-depth look at how Git stores its data and how you can recover data that seems lost, see <<ch02-git-basics-chapter#_undoing>>.
 
 ==== The Three States
 
@@ -105,4 +105,4 @@ The basic Git workflow goes something like this:
 If a particular version of a file is in the Git directory, it's considered committed.
 If it has been modified and was added to the staging area, it is staged.
 And if it was changed since it was checked out but has not been staged, it is modified.
-In <<_git_basics_chapter#_git_basics_chapter>>, you'll learn more about these states and how you can either take advantage of them or skip the staged part entirely.
+In <<ch02-git-basics-chapter#ch02-git-basics-chapter>>, you'll learn more about these states and how you can either take advantage of them or skip the staged part entirely.

book/01-introduction/sections/basics.asc

@@ -17,4 +17,4 @@ Some of the goals of the new system were as follows:
 *  Able to handle large projects like the Linux kernel efficiently (speed and data size)
 
 Since its birth in 2005, Git has evolved and matured to be easy to use and yet retain these initial qualities.
-It's amazingly fast, it's very efficient with large projects, and it has an incredible branching system for non-linear development (See <<_git_branching#_git_branching>>).
+It's amazingly fast, it's very efficient with large projects, and it has an incredible branching system for non-linear development (See <<ch03-git-branching#ch03-git-branching>>).

book/01-introduction/sections/history.asc

@@ -38,7 +38,7 @@ $ git init
 
 This creates a new subdirectory named `.git` that contains all of your necessary repository files -- a Git repository skeleton.
 At this point, nothing in your project is tracked yet.
-(See <<_git_internals#_git_internals>> for more information about exactly what files are contained in the `.git` directory you just created.)(((git commands, init)))
+(See <<ch10-git-internals#ch10-git-internals>> for more information about exactly what files are contained in the `.git` directory you just created.)(((git commands, init)))
 
 If you want to start version-controlling existing files (as opposed to an empty directory), you should probably begin tracking those files and do an initial commit.
 You can accomplish that with a few `git add` commands that specify the files you want to track, followed by a `git commit`:
@@ -60,7 +60,7 @@ If you want to get a copy of an existing Git repository -- for example, a projec
 If you're familiar with other VCS systems such as Subversion, you'll notice that the command is "clone" and not "checkout".
 This is an important distinction -- instead of getting just a working copy, Git receives a full copy of nearly all data that the server has.
 Every version of every file for the history of the project is pulled down by default when you run `git clone`.
-In fact, if your server disk gets corrupted, you can often use nearly any of the clones on any client to set the server back to the state it was in when it was cloned (you may lose some server-side hooks and such, but all the versioned data would be there -- see <<_git_on_the_server#_getting_git_on_a_server>> for more details).
+In fact, if your server disk gets corrupted, you can often use nearly any of the clones on any client to set the server back to the state it was in when it was cloned (you may lose some server-side hooks and such, but all the versioned data would be there -- see <<ch04-git-on-the-server#_getting_git_on_a_server>> for more details).
 
 You clone a repository with `git clone <url>`.(((git commands, clone)))
 For example, if you want to clone the Git linkable library called `libgit2`, you can do so like this:
@@ -84,4 +84,4 @@ That command does the same thing as the previous one, but the target directory i
 
 Git has a number of different transfer protocols you can use.
 The previous example uses the `https://` protocol, but you may also see `git://` or `user@server:path/to/repo.git`, which uses the SSH transfer protocol.
-<<_git_on_the_server#_getting_git_on_a_server>> will introduce all of the available options the server can set up to access your Git repository and the pros and cons of each.
+<<ch04-git-on-the-server#_getting_git_on_a_server>> will introduce all of the available options the server can set up to access your Git repository and the pros and cons of each.

book/02-git-basics/sections/getting-a-repository.asc

@@ -34,7 +34,7 @@ This means you have a clean working directory -- in other words, none of your tr
 Git also doesn't see any untracked files, or they would be listed here.
 Finally, the command tells you which branch you're on and informs you that it has not diverged from the same branch on the server.
 For now, that branch is always ``master'', which is the default; you won't worry about it here.
-<<_git_branching#_git_branching>> will go over branches and references in detail.
+<<ch03-git-branching#ch03-git-branching>> will go over branches and references in detail.
 
 Let's say you add a new file to your project, a simple `README` file.
 If the file didn't exist before, and you run `git status`, you see your untracked file like so:
@@ -420,7 +420,7 @@ $ git commit
 ----
 
 Doing so launches your editor of choice.
-(This is set by your shell's `EDITOR` environment variable -- usually vim or emacs, although you can configure it with whatever you want using the `git config --global core.editor` command as you saw in <<_getting_started#_getting_started>>).(((editor, changing default)))(((git commands, config)))
+(This is set by your shell's `EDITOR` environment variable -- usually vim or emacs, although you can configure it with whatever you want using the `git config --global core.editor` command as you saw in <<ch01-getting-started#ch01-getting-started>>).(((editor, changing default)))(((git commands, config)))
 
 The editor displays the following text (this example is a Vim screen):
 

book/02-git-basics/sections/recording-changes.asc

@@ -67,7 +67,7 @@ origin    [email protected]:mojombo/grit.git (push)
 This means we can pull contributions from any of these users pretty easily.
 We may additionally have permission to push to one or more of these, though we can't tell that here.
 
-Notice that these remotes use a variety of protocols; we'll cover more about this in <<_git_on_the_server#_getting_git_on_a_server>>.
+Notice that these remotes use a variety of protocols; we'll cover more about this in <<ch04-git-on-the-server#_getting_git_on_a_server>>.
 
 ==== Adding Remote Repositories
 
@@ -103,7 +103,7 @@ From https://github.com/paulboone/ticgit
 ----
 
 Paul's master branch is now accessible locally as `pb/master` -- you can merge it into one of your branches, or you can check out a local branch at that point if you want to inspect it.
-(We'll go over what branches are and how to use them in much more detail in <<_git_branching#_git_branching>>.)
+(We'll go over what branches are and how to use them in much more detail in <<ch03-git-branching#ch03-git-branching>>.)
 
 [[_fetching_and_pulling]]
 ==== Fetching and Pulling from Your Remotes
@@ -123,7 +123,7 @@ So, `git fetch origin` fetches any new work that has been pushed to that server
 It's important to note that the `git fetch` command only downloads the data to your local repository -- it doesn't automatically merge it with any of your work or modify what you're currently working on.
 You have to merge it manually into your work when you're ready.
 
-If your current branch is set up to track a remote branch (see the next section and <<_git_branching#_git_branching>> for more information), you can use the `git pull` command to automatically fetch and then merge that remote branch into your current branch.(((git commands, pull)))
+If your current branch is set up to track a remote branch (see the next section and <<ch03-git-branching#ch03-git-branching>> for more information), you can use the `git pull` command to automatically fetch and then merge that remote branch into your current branch.(((git commands, pull)))
 This may be an easier or more comfortable workflow for you; and by default, the `git clone` command automatically sets up your local master branch to track the remote master branch (or whatever the default branch is called) on the server you cloned from.
 Running `git pull` generally fetches data from the server you originally cloned from and automatically tries to merge it into the code you're currently working on.
 
@@ -142,7 +142,7 @@ $ git push origin master
 This command works only if you cloned from a server to which you have write access and if nobody has pushed in the meantime.
 If you and someone else clone at the same time and they push upstream and then you push upstream, your push will rightly be rejected.
 You'll have to fetch their work first and incorporate it into yours before you'll be allowed to push.
-See <<_git_branching#_git_branching>> for more detailed information on how to push to remote servers.
+See <<ch03-git-branching#ch03-git-branching>> for more detailed information on how to push to remote servers.
 
 [[_inspecting_remote]]
 ==== Inspecting a Remote

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

@@ -92,7 +92,7 @@ However, in the scenario described above, the file in your working directory is
 =====
 
 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#_git_reset>>.
+We'll go into much more detail about what `reset` does and how to master it to do really interesting things in <<ch07-git-tools#_git_reset>>.
 
 ==== Unmodifying a Modified File
 
@@ -134,8 +134,8 @@ Any changes you made to that file are gone -- Git just copied another file over
 Don't ever use this command unless you absolutely know that you don't want the file.
 =====
 
-If you would like to keep the changes you've made to that file but still need to get it out of the way for now, we'll go over stashing and branching in <<_git_branching#_git_branching>>; these are generally better ways to go.
+If you would like to keep the changes you've made to that file but still need to get it out of the way for now, we'll go over stashing and branching in <<ch03-git-branching#ch03-git-branching>>; these are generally better ways to go.
 
 Remember, anything that is _committed_ in Git can almost always be recovered.
-Even commits that were on branches that were deleted or commits that were overwritten with an `--amend` commit can be recovered (see <<_git_internals#_data_recovery>> for data recovery).
+Even commits that were on branches that were deleted or commits that were overwritten with an `--amend` commit can be recovered (see <<ch10-git-internals#_data_recovery>> for data recovery).
 However, anything you lose that was never committed is likely never to be seen again.

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

@@ -182,7 +182,7 @@ a11bef0 - Scott Chacon, 6 years ago : first commit
 You may be wondering what the difference is between _author_ and _committer_.
 The author is the person who originally wrote the work, whereas the committer is the person who last applied the work.
 So, if you send in a patch to a project and one of the core members applies the patch, both of you get credit -- you as the author, and the core member as the committer.
-We'll cover this distinction a bit more in <<_distributed_git#_distributed_git>>.
+We'll cover this distinction a bit more in <<ch05-distributed-git#ch05-distributed-git>>.
 
 The `oneline` and `format` options are particularly useful with another `log` option called `--graph`.
 This option adds a nice little ASCII graph showing your branch and merge history: