Switch to asciidoctor 2.0.10

C-git-commands.asc

@@ -41,7 +41,7 @@ In <<ch08-customizing-git#_keyword_expansion>> we showed how to set up smudge an
 
 Finally, basically the entirety of <<ch08-customizing-git#_git_config>> is dedicated to the command.
 
-[[_core_editor]]
+[[ch_core_editor]]
 ==== git config core.editor commands
 
 Accompanying the configuration instructions in <<ch01-getting-started#_editor>>, many editors can be set as follows:
@@ -97,7 +97,7 @@ To take a directory and turn it into a new Git repository so you can start versi
 
 We first introduce this in <<ch02-git-basics-chapter#_getting_a_repo>>, where we show creating a brand new repository to start working with.
 
-We talk briefly about how you can change the default branch name from ``master'' in <<ch03-git-branching#_remote_branches>>.
+We talk briefly about how you can change the default branch name from "`master`" in <<ch03-git-branching#_remote_branches>>.
 
 We use this command to create an empty bare repository for a server in <<ch04-git-on-the-server#_bare_repo>>.
 
@@ -127,7 +127,7 @@ For the basic workflow of staging content and committing it to your history, the
 
 ==== git add
 
-The `git add` command adds content from the working directory into the staging area (or ``index'') for the next commit.
+The `git add` command adds content from the working directory into the staging area (or "`index`") for the next commit.
 When the `git commit` command is run, by default it only looks at this staging area, so `git add` is used to craft what exactly you would like your next commit snapshot to look like.
 
 This command is an incredibly important command in Git and is mentioned or used dozens of times in this book.
@@ -367,7 +367,7 @@ This can help you be very specific about what work you wish to share.
 ==== git remote
 
 The `git remote` command is a management tool for your record of remote repositories.
-It allows you to save long URLs as short handles, such as ``origin'' so you don't have to type them out all the time.
+It allows you to save long URLs as short handles, such as "`origin`" so you don't have to type them out all the time.
 You can have several of these and the `git remote` command is used to add, change and delete them.
 
 This command is covered in detail in <<ch02-git-basics-chapter#_remote_repos>>, including listing, adding, removing and renaming them.
@@ -543,7 +543,7 @@ If you're administering a Git repository or need to fix something in a big way,
 
 ==== git gc
 
-The `git gc` command runs ``garbage collection'' on your repository, removing unnecessary files in your database and packing up the remaining files into a more efficient format.
+The `git gc` command runs "`garbage collection`" on your repository, removing unnecessary files in your database and packing up the remaining files into a more efficient format.
 
 This command normally runs in the background for you, though you can manually run it if you wish.
 We go over some examples of this in <<ch10-git-internals#_git_gc>>.

Gemfile

@@ -1,15 +1,15 @@
 source 'https://rubygems.org'
 
-gem 'rake'
-gem 'asciidoctor', '1.5.6.2'
+gem 'rake', ' 13.0.1'
+gem 'asciidoctor', '2.0.10'
 
-gem 'json'
-gem 'awesome_print'
+gem 'json', '2.3.1'
+gem 'awesome_print', '1.8.0'
 
-gem 'asciidoctor-epub3', '~> 1.5.0.alpha.9'
-gem 'asciidoctor-pdf', '~> 1.5.0.beta.8'
+gem 'asciidoctor-epub3', '1.5.0.alpha.18'
+gem 'asciidoctor-pdf', '1.5.3'
 
-gem 'coderay'
-gem 'pygments.rb'
-gem 'thread_safe'
-gem 'epubcheck'
+gem 'coderay', '1.1.3'
+gem 'pygments.rb', '1.2.1'
+gem 'thread_safe', '0.3.6'
+gem 'epubcheck', '3.0.1'

TRANSLATING.md

@@ -59,7 +59,7 @@ If there is no project for your language, you can start your own translation.
 Base your work on the second edition of the book, available [here](https://github.com/progit/progit2). To do so:
  1. Pick the correct [ISO 639 code](https://en.wikipedia.org/wiki/List_of_ISO_639-1_codes) for your language.
  1. Create a [GitHub organization](https://docs.github.com/en/github/setting-up-and-managing-organizations-and-teams/creating-a-new-organization-from-scratch), for example: `progit2-[your code]` on GitHub.
- 1. Create a project ``progit2``.
+ 1. Create a project "`progit2"`.
  1. Copy the structure of progit/progit2 (this project) in your project and start translating.
 
 ### Updating the status of your translation

book/01-introduction/sections/about-version-control.asc

@@ -1,7 +1,7 @@
 === About Version Control
 
 (((version control)))
-What is ``version control'', and why should you care?
+What is "`version control`", and why should you care?
 Version control is a system that records changes to a file or set of files over time so that you can recall specific versions later.
 For the examples in this book, you will use software source code as the files being version controlled, though in reality you can do this with nearly any type of file on a computer.
 

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

@@ -75,7 +75,7 @@ $ git config --global core.editor "'C:/Program Files/Notepad++/notepad++.exe' -m
 [NOTE]
 ====
 Vim, Emacs and Notepad++ are popular text editors often used by developers on Unix-based systems like Linux and macOS or a Windows system.
-If you are using another editor, or a 32-bit version, please find specific instructions for how to set up your favorite editor with Git in <<C-git-commands#_core_editor>>.
+If you are using another editor, or a 32-bit version, please find specific instructions for how to set up your favorite editor with Git in <<C-git-commands#ch_core_editor>>.
 ====
 
 [WARNING]

book/01-introduction/sections/help.asc

@@ -21,7 +21,7 @@ These commands are nice because you can access them anywhere, even offline.
 If the manpages and this book aren't enough and you need in-person help, you can try the `#git` or `#github` channel on the Freenode IRC server, which can be found at https://freenode.net[].
 These channels are regularly filled with hundreds of people who are all very knowledgeable about Git and are often willing to help.(((IRC)))
 
-In addition, if you don't need the full-blown manpage help, but just need a quick refresher on the available options for a Git command, you can ask for the more concise ``help'' output with the `-h` option, as in:
+In addition, if you don't need the full-blown manpage help, but just need a quick refresher on the available options for a Git command, you can ask for the more concise "`help`" output with the `-h` option, as in:
 
 [source,console]
 ----

book/01-introduction/sections/what-is-git.asc

@@ -92,7 +92,7 @@ The working tree 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.
-Its technical name in Git parlance is the ``index'', but the phrase ``staging area'' works just as well.
+Its technical name in Git parlance is the "`index`", but the phrase "`staging area`" works just as well.
 
 The Git directory is where Git stores the metadata and object database for your project.
 This is the most important part of Git, and it is what is copied when you _clone_ a repository from another computer.

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

@@ -53,7 +53,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.
@@ -83,7 +83,7 @@ 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 subsequent 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.
@@ -111,10 +111,10 @@ Changes not staged for commit:
 
 ----
 
-The `CONTRIBUTING.md` file appears under a section named ``Changes not staged for commit'' -- which means that a file that is tracked has been modified in the working directory but not yet staged.
+The `CONTRIBUTING.md` file appears under a section named "`Changes 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 precisely this content to the next commit'' rather than ``add this file to the project''.(((git commands, add)))
+It may be helpful to think of it more as "`add precisely 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 `CONTRIBUTING.md` file, and then run `git status` again:
 
 [source,console]
@@ -212,7 +212,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 whose names 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 for your new repository 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.
@@ -509,7 +509,7 @@ This is convenient, but be careful; sometimes this flag will cause you to includ
 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 ``Changes not staged for commit'' (that is, _unstaged_) area of your `git status` output:
+If you simply remove the file from your working directory, it shows up under the "`Changes not staged for commit`" (that is, _unstaged_) area of your `git status` output:
 
 [source,console]
 ----

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

@@ -11,8 +11,8 @@ In this section, we'll cover some of these remote-management skills.
 [NOTE]
 .Remote repositories can be on your local machine.
 ====
-It is entirely possible that you can be working with a ``remote'' repository that is, in fact, on the same host you are.
-The word ``remote'' does not necessarily imply that the repository is somewhere else on the network or Internet, only that it is elsewhere.
+It is entirely possible that you can be working with a "`remote`" repository that is, in fact, on the same host you are.
+The word "`remote`" does not necessarily imply that the repository is somewhere else on the network or Internet, only that it is elsewhere.
 Working with such a remote repository would still involve all the standard pushing, pulling and fetching operations as with any other remote.
 ====
 
@@ -118,7 +118,7 @@ $ git fetch <remote>
 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 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.

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

@@ -147,7 +147,7 @@ a6b4c97498bd301d84096da251c98a07c7723e65 Create write support
 8a5cbc430f1a9c3d00faaeffd07798508422908a Update readme
 ----
 
-Now, suppose you forgot to tag the project at v1.2, which was at the ``Update rakefile'' commit.
+Now, suppose you forgot to tag the project at v1.2, which was at the "`Update 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:
 
@@ -258,7 +258,7 @@ $ git push origin --delete <tagname>
 
 ==== Checking out Tags
 
-If you want to view the versions of files a tag is pointing to, you can do a `git checkout` of that tag, although this puts your repository in ``detached HEAD'' state, which has some ill side effects:
+If you want to view the versions of files a tag is pointing to, you can do a `git checkout` of that tag, although this puts your repository in "`detached HEAD`" state, which has some ill side effects:
 
 [source,console]
 ----
@@ -287,7 +287,7 @@ Previous HEAD position was 99ada87... Merge pull request #89 from schacon/append
 HEAD is now at df3f601... Add atlas.json and cover image
 ----
 
-In ``detached HEAD'' state, if you make changes and then create a commit, the tag will stay the same, but your new commit won't belong to any branch and will be unreachable, except by the exact commit hash.
+In "`detached HEAD`" state, if you make changes and then create a commit, the tag will stay the same, but your new commit won't belong to any branch and will be unreachable, except by the exact commit hash.
 Thus, if you need to make changes -- say you're fixing a bug on an older version, for instance -- you will generally want to create a branch:
 
 [source,console]

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

@@ -36,7 +36,7 @@ You end up with a single commit -- the second commit replaces the results of the
 It's important to understand that when you're amending your last commit, you're not so much fixing it as _replacing_ it entirely with a new, improved commit that pushes the old commit out of the way and puts the new commit in its place.
 Effectively, it's as if the previous commit never happened, and it won't show up in your repository history.
 
-The obvious value to amending commits is to make minor improvements to your last commit, without cluttering your repository history with commit messages of the form, ``Oops, forgot to add a file'' or ``Darn, fixing a typo in last commit''.
+The obvious value to amending commits is to make minor improvements to your last commit, without cluttering your repository history with commit messages of the form, "`Oops, forgot to add a file`" or "`Darn, fixing a typo in last commit`".
 ====
 
 [NOTE]
@@ -67,7 +67,7 @@ Changes to be committed:
     modified:   CONTRIBUTING.md
 ----
 
-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 `CONTRIBUTING.md` file:
 
 [source,console]

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

@@ -4,7 +4,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,console]
@@ -218,7 +218,7 @@ Those are only some simple output-formatting options to `git log` -- there are m
 | `--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. Option values include oneline, short, full, fuller, and format (where you specify your own format).
 | `--oneline`       | Shorthand for `--pretty=oneline --abbrev-commit` used together.
@@ -252,7 +252,7 @@ of the `--grep` patterns; however, adding the `--all-match` option further limit
 just those commits that match _all_ `--grep` patterns.
 ====
 
-Another really helpful filter is the `-S` option (colloquially referred to as Git's ``pickaxe'' option), which takes a string and shows only those commits that changed the number of occurrences of that string.
+Another really helpful filter is the `-S` option (colloquially referred to as Git's "`pickaxe`" option), which takes a string and shows only those commits that changed the number of occurrences of that string.
 For instance, if you wanted to find the last commit that added or removed a reference to a specific function, you could call:
 
 [source,console]

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

@@ -104,9 +104,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 `C4` pointed to by the branch `hotfix` you merged in was directly ahead of the commit `C2` 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.
 
@@ -265,7 +265,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]

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

@@ -37,7 +37,7 @@ Every time you commit, the `master` branch pointer moves forward automatically.
 
 [NOTE]
 ====
-The ``master'' branch in Git is not a special branch.(((master)))
+The "`master`" branch in Git is not a special branch.(((master)))
 It is exactly like any other branch.
 The only reason nearly every repository has one is that the `git init` command creates it by default and most people don't bother to change it.
 ====