Bold and italic follow Asciidoc semantics

The book used a combination of Markdown and Asciidoc syntax for
bold and italic text. In the documentation, it says that * are
used for highlighting the whole word or phrase, and ** are used
to highlight a part of the word. The render still worked fine
before, but the source-code now follows the semantics.

http://asciidoctor.org/docs/user-manual/#bold-and-italic

Author: lazarljubenovic

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

@@ -128,6 +128,6 @@ Don't ever use this command unless you absolutely know that you don't want the f
 
 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>>; these are generally better ways to go.
 
-Remember, anything that is __committed__ in Git can almost always be recovered.
+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 <<_data_recovery>> for data recovery).
 However, anything you lose that was never committed is likely never to be seen again.

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

@@ -137,7 +137,7 @@ image::images/interesting-rebase-5.png[Final commit history.]
 (((rebasing, perils of)))
 Ahh, but the bliss of rebasing isn't without its drawbacks, which can be summed up in a single line:
 
-**Do not rebase commits that exist outside your repository.**
+*Do not rebase commits that exist outside your repository.*
 
 If you follow that guideline, you'll be fine.
 If you don't, people will hate you, and you'll be scorned by friends and family.

book/07-git-tools/sections/advanced-merging.asc

@@ -139,7 +139,7 @@ By default, Git sees all of these lines as being changed, so it can't merge the
 
 The default merge strategy can take arguments though, and a few of them are about properly ignoring whitespace changes.
 If you see that you have a lot of whitespace issues in a merge, you can simply abort it and do it again, this time with `-Xignore-all-space` or `-Xignore-space-change`.
-The first option ignores whitespace **completely** when comparing lines, the second treats sequences of one or more whitespace characters as equivalent.
+The first option ignores whitespace *completely* when comparing lines, the second treats sequences of one or more whitespace characters as equivalent.
 
 [source,console]
 ----
@@ -432,7 +432,7 @@ $ git log --oneline --left-right --merge
 ----
 
 If you run that with the `-p` option instead, you get just the diffs to the file that ended up in conflict.
-This can be **really** helpful in quickly giving you the context you need to help understand why something conflicts and how to more intelligently resolve it.
+This can be *really* helpful in quickly giving you the context you need to help understand why something conflicts and how to more intelligently resolve it.
 
 ===== Combined Diff Format
 

book/07-git-tools/sections/replace.asc

@@ -92,7 +92,7 @@ $ echo 'get history from blah blah blah' | git commit-tree 9c68fdc^{tree}
 [NOTE]
 =====
 The `commit-tree` command is one of a set of commands that are commonly referred to as 'plumbing' commands.
-These are commands that are not generally meant to be used directly, but instead are used by **other** Git commands to do smaller jobs.
+These are commands that are not generally meant to be used directly, but instead are used by *other* Git commands to do smaller jobs.
 On occasions when we're doing weirder things like this, they allow us to do really low-level things but are not meant for daily use.
 You can read more about plumbing commands in <<_plumbing_porcelain>>
 =====

book/07-git-tools/sections/reset.asc

@@ -185,7 +185,7 @@ If you use the `--hard` option, it will continue to this stage.
 image::images/reset-hard.png[]
 
 So let's think about what just happened.
-You undid your last commit, the `git add` and `git commit` commands, **and** all the work you did in your working directory.
+You undid your last commit, the `git add` and `git commit` commands, *and* all the work you did in your working directory.
 
 It's important to note that this flag (`--hard`) is the only way to make the `reset` command dangerous, and one of the very few cases where Git will actually destroy data.
 Any other invocation of `reset` can be pretty easily undone, but the `--hard` option cannot, since it forcibly overwrites files in the Working Directory.

book/07-git-tools/sections/searching.asc

@@ -92,7 +92,7 @@ As we saw in the above example, we looked for terms in an older version of the G
 
 ==== Git Log Searching
 
-Perhaps you're looking not for **where** a term exists, but **when** it existed or was introduced.
+Perhaps you're looking not for *where* a term exists, but *when* it existed or was introduced.
 The `git log` command has a number of powerful tools for finding specific commits by the content of their messages or even the content of the diff they introduce.
 
 If we want to find out for example when the `ZLIB_BUF_MAX` constant was originally introduced, we can tell Git to only show us the commits that either added or removed that string with the `-S` option.

book/07-git-tools/sections/submodules.asc

@@ -363,7 +363,7 @@ Submodule DbConnector c3f01dc..c87d55d:
   > better connection routine
 ----
 
-Git will by default try to update **all** of your submodules when you run `git submodule update --remote` so if you have a lot of them, you may want to pass the name of just the submodule you want to try to update.
+Git will by default try to update *all* of your submodules when you run `git submodule update --remote` so if you have a lot of them, you may want to pass the name of just the submodule you want to try to update.
 
 ===== Working on a Submodule
 
@@ -647,11 +647,11 @@ $ git commit -m "Merge Tom's Changes" <5>
 It can be a bit confusing, but it's really not very hard.
 
 Interestingly, there is another case that Git handles.
-If a merge commit exists in the submodule directory that contains **both** commits in its history, Git will suggest it to you as a possible solution.
+If a merge commit exists in the submodule directory that contains *both* commits in its history, Git will suggest it to you as a possible solution.
 It sees that at some point in the submodule project, someone merged branches containing these two commits, so maybe you'll want that one.
 
 This is why the error message from before was ``merge following commits not found'', because it could not do *this*.
-It's confusing because who would expect it to **try** to do this?
+It's confusing because who would expect it to *try* to do this?
 
 If it does find a single acceptable merge commit, you'll see something like this: