replace all `quotes'' with "quotes`", which is the correct asciidoc

Author: schacon

README.asc

@@ -24,5 +24,5 @@ The images in this book were generated using Sketch 3, with the [included sketch
 To add a figure:
 
 . Add a page to the sketchbook. Try to use the included symbols wherever possible.
-. Add a ``slice'' to your page. Give it a name that matches the destination PNG filename, relative from the root of the source directory.
+. Add a "`slice`" to your page. Give it a name that matches the destination PNG filename, relative from the root of the source directory.
 . Make sure your slice is set to export at 3x size.

book/01-introduction/sections/basics.asc

@@ -91,7 +91,7 @@ The working directory is a single checkout of one version of the project.
 These files are pulled out of the compressed database in the Git directory and placed on disk for you to use or modify.
 
 The staging area is a file, generally contained in your Git directory, that stores information about what will go into your next commit.
-It’s sometimes referred to as the ``index'', but it’s also common to refer to it as the staging area.
+It’s sometimes referred to as the "`index`", but it’s also common to refer to it as the staging area.
 
 The basic Git workflow goes something like this:
 

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

@@ -46,9 +46,9 @@ For example, if you want to clone the Git linkable library called libgit2, you c
 $ git clone https://github.com/libgit2/libgit2
 ----
 
-That creates a directory named ``libgit2'', initializes a `.git` directory inside it, pulls down all the data for that repository, and checks out a working copy of the latest version.
+That creates a directory named "`libgit2`", initializes a `.git` directory inside it, pulls down all the data for that repository, and checks out a working copy of the latest version.
 If you go into the new `libgit2` directory, you’ll see the project files in there, ready to be worked on or used.
-If you want to clone the repository into a directory named something other than ``libgit2'', you can specify that as the next command-line option:
+If you want to clone the repository into a directory named something other than "`libgit2`", you can specify that as the next command-line option:
 
 [source,shell]
 ----

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

@@ -29,7 +29,7 @@ nothing to commit, working directory clean
 This means you have a clean working directory – in other words, there are no tracked and modified files.
 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.
+For now, that branch is always "`master`", which is the default; you won’t worry about it here.
 <<_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.
@@ -48,7 +48,7 @@ Untracked files:
 nothing added to commit but untracked files present (use "git add" to track)
 ----
 
-You can see that your new README file is untracked, because it’s under the ``Untracked files'' heading in your status output.
+You can see that your new README file is untracked, because it’s under the "`Untracked files`" heading in your status output.
 Untracked basically means that Git sees a file you didn’t have in the previous snapshot (commit); Git won’t start including it in your commit snapshots until you explicitly tell it to do so.
 It does this so you don’t accidentally begin including generated binary files or other files that you did not mean to include.
 You do want to start including README, so let’s start tracking the file.
@@ -76,15 +76,15 @@ Changes to be committed:
 
 ----
 
-You can tell that it’s staged because it’s under the ``Changes to be committed'' heading.
+You can tell that it’s staged because it’s under the "`Changes to be committed`" heading.
 If you commit at this point, the version of the file at the time you ran `git add` is what will be in the historical snapshot.
 You may recall that when you ran `git init` earlier, you then ran `git add (files)` – that was to begin tracking files in your directory.(((git commands, init)))(((git commands, add)))
 The `git add` command takes a path name for either a file or a directory; if it’s a directory, the command adds all the files in that directory recursively.
 
 ==== Staging Modified Files
 
 Let’s change a file that was already tracked.
-If you change a previously tracked file called ``benchmarks.rb'' and then run your `git status` command again, you get something that looks like this:
+If you change a previously tracked file called "`benchmarks.rb`" and then run your `git status` command again, you get something that looks like this:
 
 [source,shell]
 ----
@@ -103,9 +103,9 @@ Changes not staged for commit:
 
 ----
 
-The ``benchmarks.rb'' file appears under a section named ``Changed but not staged for commit'' – which means that a file that is tracked has been modified in the working directory but not yet staged.
-To stage it, you run the `git add` command. `git add` is a multipurpose command – you use it to begin tracking new files, to stage files, and to do other things like marking merge-conflicted files as resolved. It may be helpful to think of it more as ``add this content to the next commit'' rather than ``add this file to the project''.(((git commands, add)))
-Let’s run `git add` now to stage the ``benchmarks.rb'' file, and then run `git status` again:
+The "`benchmarks.rb`" file appears under a section named "`Changed but not staged for commit`" – which means that a file that is tracked has been modified in the working directory but not yet staged.
+To stage it, you run the `git add` command. `git add` is a multipurpose command – you use it to begin tracking new files, to stage files, and to do other things like marking merge-conflicted files as resolved. It may be helpful to think of it more as "`add this content to the next commit`" rather than "`add this file to the project`".(((git commands, add)))
+Let’s run `git add` now to stage the "`benchmarks.rb`" file, and then run `git status` again:
 
 [source,shell]
 ----
@@ -194,7 +194,7 @@ $ cat .gitignore
 *~
 ----
 
-The first line tells Git to ignore any files ending in ``.o'' or ``.a'' – object and archive files that may be the product of building your code.
+The first line tells Git to ignore any files ending in "`.o`" or "`.a`" – object and archive files that may be the product of building your code.
 The second line tells Git to ignore all files that end with a tilde (`~`), which is used by many text editors such as Emacs to mark temporary files.
 You may also include a log, tmp, or pid directory; automatically generated documentation; and so on.
 Setting up a `.gitignore` file before you get going is generally a good idea so you don’t accidentally commit files that you really don’t want in your Git repository.
@@ -437,15 +437,15 @@ $ git commit -a -m 'added new benchmarks'
  1 file changed, 5 insertions(+), 0 deletions(-)
 ----
 
-Notice how you don’t have to run `git add` on the ``benchmarks.rb'' file in this case before you commit.
+Notice how you don’t have to run `git add` on the "`benchmarks.rb`" file in this case before you commit.
 
 ==== Removing Files
 
 (((files, removing)))
 To remove a file from Git, you have to remove it from your tracked files (more accurately, remove it from your staging area) and then commit.
 The `git rm` command does that, and also removes the file from your working directory so you don’t see it as an untracked file the next time around.
 
-If you simply remove the file from your working directory, it shows up under the ``Changed but not updated'' (that is, _unstaged_) area of your `git status` output:
+If you simply remove the file from your working directory, it shows up under the "`Changed but not updated`" (that is, _unstaged_) area of your `git status` output:
 
 [source,shell]
 ----

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

@@ -107,7 +107,7 @@ $ git fetch [remote-name]
 The command goes out to that remote project and pulls down all the data from that remote project that you don’t have yet.
 After you do this, you should have references to all the branches from that remote, which you can merge in or inspect at any time.
 
-If you clone a repository, the command automatically adds that remote repository under the name ``origin''.
+If you clone a repository, the command automatically adds that remote repository under the name "`origin`".
 So, `git fetch origin` fetches any new work that has been pushed to that server since you cloned (or last fetched from) it.
 It’s important to note that the `git fetch` command pulls 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.

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

@@ -137,7 +137,7 @@ a6b4c97498bd301d84096da251c98a07c7723e65 beginning write support
 8a5cbc430f1a9c3d00faaeffd07798508422908a updated readme
 ----
 
-Now, suppose you forgot to tag the project at v1.2, which was at the ``updated rakefile'' commit.
+Now, suppose you forgot to tag the project at v1.2, which was at the "`updated rakefile`" commit.
 You can add it after the fact.
 To tag that commit, you specify the commit checksum (or part of it) at the end of the command:
 

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

@@ -52,7 +52,7 @@ Changes to be committed:
     modified:   benchmarks.rb
 ----
 
-Right below the ``Changes to be committed'' text, it says use `git reset HEAD <file>...` to unstage.
+Right below the "`Changes to be committed`" text, it says use `git reset HEAD <file>...` to unstage.
 So, let’s use that advice to unstage the `benchmarks.rb` file:
 
 [source,shell]

book/02-git-basics/sections/viewing-history.asc

@@ -3,7 +3,7 @@
 After you have created several commits, or if you have cloned a repository with an existing commit history, you’ll probably want to look back to see what has happened.
 The most basic and powerful tool to do this is the `git log` command.
 
-These examples use a very simple project called ``simplegit''.
+These examples use a very simple project called "`simplegit`".
 To get the project, run
 
 [source,shell]
@@ -218,7 +218,7 @@ Those are only some simple output-formatting options to `git log` – there are
 | `--name-only`     | Show the list of files modified after the commit information.
 | `--name-status`   | Show the list of files affected with added/modified/deleted information as well.
 | `--abbrev-commit` | Show only the first few characters of the SHA-1 checksum instead of all 40.
-| `--relative-date` | Display the date in a relative format (for example, ``2 weeks ago'') instead of using the full date format.
+| `--relative-date` | Display the date in a relative format (for example, "`2 weeks ago`") instead of using the full date format.
 | `--graph`         | Display an ASCII graph of the branch and merge history beside the log output.
 | `--pretty`        | Show commits in an alternate format. Options include oneline, short, full, fuller, and format (where you specify your own format).
 |================================

book/03-git-branching/1-git-branching.asc

@@ -6,7 +6,7 @@ Nearly every VCS has some form of branching support.
 Branching means you diverge from the main line of development and continue to do work without messing with that main line.
 In many VCS tools, this is a somewhat expensive process, often requiring you to create a new copy of your source code directory, which can take a long time for large projects.
 
-Some people refer to Git's branching model as its ``killer feature,'' and it certainly sets Git apart in the VCS community.
+Some people refer to Git's branching model as its "`killer feature,`" and it certainly sets Git apart in the VCS community.
 Why is it so special?
 The way Git branches is incredibly lightweight, making branching operations nearly instantaneous, and switching back and forth between branches generally just as fast.
 Unlike many other VCSs, Git encourages workflows that branch and merge often, even multiple times in a day.

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

@@ -103,9 +103,9 @@ Fast-forward
  1 file changed, 2 insertions(+)
 ----
 
-You'll notice the phrase ``fast-forward'' in that merge.
+You'll notice the phrase "`fast-forward`" in that merge.
 Because the commit pointed to by the branch you merged in was directly upstream of the commit you're on, Git simply moves the pointer forward.
-To phrase that another way, when you try to merge one commit with a commit that can be reached by following the first commit's history, Git simplifies things by moving the pointer forward because there is no divergent work to merge together – this is called a ``fast-forward.''
+To phrase that another way, when you try to merge one commit with a commit that can be reached by following the first commit's history, Git simplifies things by moving the pointer forward because there is no divergent work to merge together – this is called a "`fast-forward.`"
 
 Your change is now in the snapshot of the commit pointed to by the `master` branch, and you can deploy the fix.
 
@@ -266,7 +266,7 @@ Normal merge conflict for 'index.html':
 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.''
+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.
 
 [NOTE]