change name of chapters to adapt to git-scm scripts

_git_in_other_environments.asc → 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 → 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
 

book/01-introduction/sections/basics.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/history.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/02-git-basics/sections/getting-a-repository.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/recording-changes.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/remotes.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/undoing.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/viewing-history.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:

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

@@ -62,7 +62,7 @@ All you have to do is switch back to your `master` branch.
 
 However, before you do that, note that if your working directory or staging area has uncommitted changes that conflict with the branch you're checking out, Git won't let you switch branches.
 It's best to have a clean working state when you switch branches.
-There are ways to get around this (namely, stashing and commit amending) that we'll cover later on, in <<_git_tools#_git_stashing>>.
+There are ways to get around this (namely, stashing and commit amending) that we'll cover later on, in <<ch07-git-tools#_git_stashing>>.
 For now, let's assume you've committed all your changes, so you can switch back to your `master` branch:
 
 [source,console]
@@ -273,7 +273,7 @@ Just type the name of the tool you'd rather use.
 
 [NOTE]
 ====
-If you need more advanced tools for resolving tricky merge conflicts, we cover more on merging in <<_git_tools#_advanced_merging>>.
+If you need more advanced tools for resolving tricky merge conflicts, we cover more on merging in <<ch07-git-tools#_advanced_merging>>.
 ====
 
 After you exit the merge tool, Git asks you if the merge was successful.

book/03-git-branching/sections/nutshell.asc

@@ -3,13 +3,13 @@
 
 To really understand the way Git does branching, we need to take a step back and examine how Git stores its data.
 
-As you may remember from <<_getting_started#_getting_started>>, Git doesn't store data as a series of changesets or differences, but instead as a series of snapshots.
+As you may remember from <<ch01-getting-started#ch01-getting-started>>, Git doesn't store data as a series of changesets or differences, but instead as a series of snapshots.
 
 When you make a commit, Git stores a commit object that contains a pointer to the snapshot of the content you staged.
 This object also contains the author's name and email, the message that you typed, and pointers to the commit or commits that directly came before this commit (its parent or parents): zero parents for the initial commit, one parent for a normal commit, and multiple parents for a commit that results from a merge of two or more branches.
 
 To visualize this, let's assume that you have a directory containing three files, and you stage them all and commit.
-Staging the files computes a checksum for each one (the SHA-1 hash we mentioned in <<_getting_started#_getting_started>>), stores that version of the file in the Git repository (Git refers to them as blobs), and adds that checksum to the staging area:
+Staging the files computes a checksum for each one (the SHA-1 hash we mentioned in <<ch01-getting-started#ch01-getting-started>>), stores that version of the file in the Git repository (Git refers to them as blobs), and adds that checksum to the staging area:
 
 [source,console]
 ----

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

@@ -44,7 +44,7 @@ image::images/remote-branches-3.png[`git fetch` updates your remote references.]
 
 To demonstrate having multiple remote servers and what remote branches for those remote projects look like, let's assume you have another internal Git server that is used only for development by one of your sprint teams.
 This server is at `git.team1.ourcompany.com`.
-You can add it as a new remote reference to the project you're currently working on by running the `git remote add` command as we covered in <<_git_basics_chapter#_git_basics_chapter>>.
+You can add it as a new remote reference to the project you're currently working on by running the `git remote add` command as we covered in <<ch02-git-basics-chapter#ch02-git-basics-chapter>>.
 Name this remote `teamone`, which will be your shortname for that whole URL.
 
 .Adding another server as a remote
@@ -81,7 +81,7 @@ To https://github.com/schacon/simplegit
 
 This is a bit of a shortcut.
 Git automatically expands the `serverfix` branchname out to `refs/heads/serverfix:refs/heads/serverfix`, which means, ``Take my serverfix local branch and push it to update the remote's serverfix branch.''
-We'll go over the `refs/heads/` part in detail in <<_git_internals#_git_internals>>, but you can generally leave it off.
+We'll go over the `refs/heads/` part in detail in <<ch10-git-internals#ch10-git-internals>>, but you can generally leave it off.
 You can also do `git push origin serverfix:serverfix`, which does the same thing -- it says, ``Take my serverfix and make it the remote's serverfix.''
 You can use this format to push a local branch into a remote branch that is named differently.
 If you didn't want it to be called `serverfix` on the remote, you could instead run `git push origin serverfix:awesomebranch` to push your local `serverfix` branch to the `awesomebranch` branch on the remote project.
@@ -95,7 +95,7 @@ By default it will prompt you on the terminal for this information so the server
 If you don't want to type it every single time you push, you can set up a ``credential cache''.
 The simplest is just to keep it in memory for a few minutes, which you can easily set up by running `git config --global credential.helper cache`.
 
-For more information on the various credential caching options available, see <<_git_tools#_credential_caching>>.
+For more information on the various credential caching options available, see <<ch07-git-tools#_credential_caching>>.
 ====
 
 The next time one of your collaborators fetches from the server, they will get a reference to where the server's version of `serverfix` is under the remote branch `origin/serverfix`:

book/03-git-branching/sections/workflows.asc

@@ -57,7 +57,7 @@ Your history then looks like this:
 .History after merging `dumbidea` and `iss91v2`
 image::images/topic-branches-2.png[History after merging `dumbidea` and `iss91v2`.]
 
-We will go into more detail about the various possible workflows for your Git project in <<_distributed_git#_distributed_git>>, so before you decide which branching scheme your next project will use, be sure to read that chapter.
+We will go into more detail about the various possible workflows for your Git project in <<ch05-distributed-git#ch05-distributed-git>>, so before you decide which branching scheme your next project will use, be sure to read that chapter.
 
 It's important to remember when you're doing all this that these branches are completely local.
 When you're branching and merging, everything is being done only in your Git repository -- no server communication is happening.

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

@@ -7,4 +7,4 @@ Even if you set up and run your own server internally, you may still want to use
 These days, you have a huge number of hosting options to choose from, each with different advantages and disadvantages.
 To see an up-to-date list, check out the GitHosting page on the main Git wiki at https://git.wiki.kernel.org/index.php/GitHosting[]
 
-We'll cover using GitHub in detail in <<_github#_github>>, as it is the largest Git host out there and you may need to interact with projects hosted on it in any case, but there are dozens more to choose from should you not want to set up your own Git server.
+We'll cover using GitHub in detail in <<ch06-github#ch06-github>>, as it is the largest Git host out there and you may need to interact with projects hosted on it in any case, but there are dozens more to choose from should you not want to set up your own Git server.