Merge pull request #1858 from petk/patch-formatting

Add more text formatting

Author: ben

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

@@ -170,7 +170,7 @@ a11bef0 - Scott Chacon, 6 years ago : Initial commit
 | `%p`      | Abbreviated parent hashes
 | `%an`     | Author name
 | `%ae`     | Author email
-| `%ad`     | Author date (format respects the --date=option)
+| `%ad`     | Author date (format respects the `--date=option`)
 | `%ar`     | Author date, relative
 | `%cn`     | Committer name
 | `%ce`     | Committer email
@@ -205,7 +205,7 @@ $ git log --pretty=format:"%h %s" --graph
 This type of output will become more interesting as we go through branching and merging in the next chapter.
 
 Those are only some simple output-formatting options to `git log` -- there are many more.
-<<log_options>> lists the options we've covered so far, as well as some other common formatting options that may be useful, along with how they change the output of the log command.
+<<log_options>> lists the options we've covered so far, as well as some other common formatting options that may be useful, along with how they change the output of the `log` command.
 
 [[log_options]]
 .Common options to `git log`
@@ -214,13 +214,13 @@ Those are only some simple output-formatting options to `git log` -- there are m
 | Option            | Description
 | `-p`              | Show the patch introduced with each commit.
 | `--stat`          | Show statistics for files modified in each commit.
-| `--shortstat`     | Display only the changed/insertions/deletions line from the --stat command.
+| `--shortstat`     | Display only the changed/insertions/deletions line from the `--stat` command.
 | `--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.
 | `--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).
+| `--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.
 |================================
 
@@ -305,5 +305,5 @@ Of the nearly 40,000 commits in the Git source code history, this command shows
 .Preventing the display of merge commits
 ====
 Depending on the workflow used in your repository, it's possible that a sizable percentage of the commits in your log history are just merge commits, which typically aren't very informative.
-To prevent the display of merge commits cluttering up your log history, simply add the log option `--no-merges`.
+To prevent the display of merge commits cluttering up your log history, simply add the `log` option `--no-merges`.
 ====

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

@@ -66,7 +66,7 @@ You can also have your rebase replay on something other than the rebase target b
 Take a history like <<rbdiag_e>>, for example.
 You branched a topic branch (`server`) to add some server-side functionality to your project, and made a commit.
 Then, you branched off that to make the client-side changes (`client`) and committed a few times.
-Finally, you went back to your server branch and did a few more commits.
+Finally, you went back to your `server` branch and did a few more commits.
 
 [[rbdiag_e]]
 .A history with a topic branch off another topic branch
@@ -95,10 +95,10 @@ $ git merge client
 ----
 
 [[rbdiag_g]]
-.Fast-forwarding your `master` branch to include the client branch changes
-image::images/interesting-rebase-3.png[Fast-forwarding your `master` branch to include the client branch changes]
+.Fast-forwarding your `master` branch to include the `client` branch changes
+image::images/interesting-rebase-3.png[Fast-forwarding your `master` branch to include the `client` branch changes]
 
-Let's say you decide to pull in your server branch as well.
+Let's say you decide to pull in your `server` branch as well.
 You can rebase the `server` branch onto the `master` branch without having to check it out first by running `git rebase <basebranch> <topicbranch>` -- which checks out the topic branch (in this case, `server`) for you and replays it onto the base branch (`master`):
 
 [source,console]
@@ -109,8 +109,8 @@ $ git rebase master server
 This replays your `server` work on top of your `master` work, as shown in <<rbdiag_h>>.
 
 [[rbdiag_h]]
-.Rebasing your server branch on top of your `master` branch
-image::images/interesting-rebase-4.png[Rebasing your server branch on top of your `master` branch]
+.Rebasing your `server` branch on top of your `master` branch
+image::images/interesting-rebase-4.png[Rebasing your `server` branch on top of your `master` branch]
 
 Then, you can fast-forward the base branch (`master`):
 
@@ -190,9 +190,9 @@ If you pull down work that was rewritten and rebase it on top of the new commits
 
 For instance, in the previous scenario, if instead of doing a merge when we're at <<_pre_merge_rebase_work>> we run `git rebase teamone/master`, Git will:
 
-* Determine what work is unique to our branch (C2, C3, C4, C6, C7)
-* Determine which are not merge commits (C2, C3, C4)
-* Determine which have not been rewritten into the target branch (just C2 and C3, since C4 is the same patch as C4')
+* Determine what work is unique to our branch (`C2`, `C3`, `C4`, `C6`, `C7`)
+* Determine which are not merge commits (`C2`, `C3`, `C4`)
+* Determine which have not been rewritten into the target branch (just `C2` and `C3`, since `C4` is the same patch as `C4'`)
 * Apply those commits to the top of `teamone/master`
 
 So instead of the result we see in <<_merge_rebase_work>>, we would end up with something more like <<_rebase_rebase_work>>.
@@ -202,7 +202,7 @@ So instead of the result we see in <<_merge_rebase_work>>, we would end up with
 image::images/perils-of-rebasing-5.png[Rebase on top of force-pushed rebase work]
 
 This only works if `C4` and `C4'` that your partner made are almost exactly the same patch.
-Otherwise the rebase won't be able to tell that it's a duplicate and will add another C4-like patch (which will probably fail to apply cleanly, since the changes would already be at least somewhat there).
+Otherwise the rebase won't be able to tell that it's a duplicate and will add another `C4`-like patch (which will probably fail to apply cleanly, since the changes would already be at least somewhat there).
 
 You can also simplify this by running a `git pull --rebase` instead of a normal `git pull`.
 Or you could do it manually with a `git fetch` followed by a `git rebase teamone/master` in this case.
@@ -230,7 +230,7 @@ That's how it happened, and the repository should preserve that for posterity.
 The opposing point of view is that the commit history is the *story of how your project was made.*
 You wouldn't publish the first draft of a book, so why show your messy work?
 When you're working on a project, you may need a record of all your missteps and dead-end paths, but when it's time to show your work to the world, you may want to tell a more coherent story of how to get from A to B.
-People in this camp use tools like rebase and filter-branch to rewrite their commits before they're merged into the mainline branch.
+People in this camp use tools like `rebase` and `filter-branch` to rewrite their commits before they're merged into the mainline branch.
 They use tools like `rebase` and `filter-branch`, to tell the story in the way that's best for future readers.
 
 Now, to the question of whether merging or rebasing is better: hopefully you'll see that it's not that simple.

book/05-distributed-git/sections/maintaining.asc

@@ -35,7 +35,7 @@ Now you're ready to add the contributed work that you received into this topic b
 If you receive a patch over email that you need to integrate into your project, you need to apply the patch in your topic branch to evaluate it.
 There are two ways to apply an emailed patch: with `git apply` or with `git am`.
 
-===== Applying a Patch with apply
+===== Applying a Patch with `apply`
 
 (((git commands, apply)))
 If you received the patch from someone who generated it with `git diff` or some variation of the Unix `diff` command (which is not recommended; see the next section), you can apply it with the `git apply` command.
@@ -533,7 +533,7 @@ You now have a nice tarball and a zip archive of your project release that you c
 (((git commands, shortlog)))
 It's time to email your mailing list of people who want to know what's happening in your project.
 A nice way of quickly getting a sort of changelog of what has been added to your project since your last release or email is to use the `git shortlog` command.
-It summarizes all the commits in the range you give it; for example, the following gives you a summary of all the commits since your last release, if your last release was named v1.0.1:
+It summarizes all the commits in the range you give it; for example, the following gives you a summary of all the commits since your last release, if your last release was named `v1.0.1`:
 
 [source,console]
 ----
@@ -553,4 +553,4 @@ Tom Preston-Werner (4):
       Regenerated gemspec for version 1.0.2
 ----
 
-You get a clean summary of all the commits since v1.0.1, grouped by author, that you can email to your list.
+You get a clean summary of all the commits since `v1.0.1`, grouped by author, that you can email to your list.

book/06-github/sections/2-contributing.asc

@@ -42,7 +42,7 @@ Here's how it generally works:
 5. Open a Pull Request on GitHub.
 6. Discuss, and optionally continue committing.
 7. The project owner merges or closes the Pull Request.
-8. Sync the updated master back to your fork.
+8. Sync the updated `master` back to your fork.
 
 This is basically the Integration Manager workflow covered in <<ch05-distributed-git#_integration_manager>>, but instead of using email to communicate and review changes, teams use GitHub's web based tools.
 

book/06-github/sections/3-maintaining.asc

@@ -324,7 +324,7 @@ There are a couple of special files that GitHub will notice if they are present
 
 The first is the `README` file, which can be of nearly any format that GitHub recognizes as prose.
 For example, it could be `README`, `README.md`, `README.asciidoc`, etc.
-If GitHub sees a README file in your source, it will render it on the landing page of the project.
+If GitHub sees a `README` file in your source, it will render it on the landing page of the project.
 
 Many teams use this file to hold all the relevant project information for someone who might be new to the repository or project.
 This generally includes things like:

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

@@ -116,7 +116,7 @@ For the `get` action, however, Git is very interested in what the helper has to
 If the helper doesn't know anything useful, it can simply exit with no output, but if it does know, it should augment the provided information with the information it has stored.
 The output is treated like a series of assignment statements; anything provided will replace what Git already knows.
 
-Here's the same example from above, but skipping git-credential and going straight for git-credential-store:
+Here's the same example from above, but skipping `git-credential` and going straight for `git-credential-store`:
 
 [source,console]
 ----

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

@@ -171,7 +171,7 @@ When you run `git commit`, Git creates a new commit and moves the branch that HE
 When you `reset` back to `HEAD~` (the parent of HEAD), you are moving the branch back to where it was, without changing the index or working directory.
 You could now update the index and run `git commit` again to accomplish what `git commit --amend` would have done (see <<_git_amend>>).
 
-===== Step 2: Updating the Index (--mixed)
+===== Step 2: Updating the Index (`--mixed`)
 
 Note that if you run `git status` now you'll see in green the difference between the index and what the new HEAD is.
 
@@ -186,7 +186,7 @@ This is also the default, so if you specify no option at all (just `git reset HE
 Now take another second to look at that diagram and realize what happened: it still undid your last `commit`, but also _unstaged_ everything.
 You rolled back to before you ran all your `git add` and `git commit` commands.
 
-===== Step 3: Updating the Working Directory (--hard)
+===== Step 3: Updating the Working Directory (`--hard`)
 
 The third thing that `reset` will do is to make the working directory look like the index.
 If you use the `--hard` option, it will continue to this stage.
@@ -271,8 +271,8 @@ And then simply run `git commit` again:
 .Git repository with squashed commit
 image::images/reset-squash-r3.png[Git repository with squashed commit]
 
-Now you can see that your reachable history, the history you would push, now looks like you had one commit with `file-a.txt` v1, then a second that both modified `file-a.txt` to v3 and added `file-b.txt`.
-The commit with the v2 version of the file is no longer in the history.
+Now you can see that your reachable history, the history you would push, now looks like you had one commit with `file-a.txt` *v1*, then a second that both modified `file-a.txt` to *v3* and added `file-b.txt`.
+The commit with the *v2* version of the file is no longer in the history.
 
 ==== Check It Out
 

book/07-git-tools/sections/rewriting-history.asc

@@ -166,7 +166,7 @@ $ git rebase --continue
 ----
 
 This command will apply the other two commits automatically, and then you're done.
-If you change pick to edit on more lines, you can repeat these steps for each commit you change to edit.
+If you change `pick` to `edit` on more lines, you can repeat these steps for each commit you change to `edit`.
 Each time, Git will stop, let you amend the commit, and continue when you're finished.
 
 ==== Reordering Commits

book/07-git-tools/sections/stashing-cleaning.asc

@@ -114,7 +114,7 @@ Changes not staged for commit:
 	modified:   lib/simplegit.rb
 ----
 
-The apply option only tries to apply the stashed work -- you continue to have it on your stack.
+The `apply` option only tries to apply the stashed work -- you continue to have it on your stack.
 To remove it, you can run `git stash drop` with the name of the stash to remove:
 
 [source,console]
@@ -249,7 +249,7 @@ Would remove tmp/
 
 By default, the `git clean` command will only remove untracked files that are not ignored.
 Any file that matches a pattern in your `.gitignore` or other ignore files will not be removed.
-If you want to remove those files too, such as to remove all `.o` files generated from a build so you can do a fully clean build, you can add a `-x` to the clean command.
+If you want to remove those files too, such as to remove all `.o` files generated from a build so you can do a fully clean build, you can add a `-x` to the `clean` command.
 
 [source,console]
 ----
@@ -271,7 +271,7 @@ Would remove tmp/
 If you don't know what the `git clean` command is going to do, always run it with a `-n` first to double check before changing the `-n` to a `-f` and doing it for real.
 The other way you can be careful about the process is to run it with the `-i` or "`interactive`" flag.
 
-This will run the clean command in an interactive mode.
+This will run the `clean` command in an interactive mode.
 
 [source,console]
 ----

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

@@ -264,7 +264,7 @@ Submodule path 'DbConnector': checked out 'd0354fc054692d3906c85c3af05ddce39a1c0
 
 This command will by default assume that you want to update the checkout to the default branch of the remote submodule repository (the one pointed to by `HEAD` on the remote).
 You can, however, set this to something different if you want.
-For example, if you want to have the DbConnector submodule track that repository's "`stable`" branch, you can set it in either your `.gitmodules` file (so everyone else also tracks it), or just in your local `.git/config` file.
+For example, if you want to have the `DbConnector` submodule track that repository's "`stable`" branch, you can set it in either your `.gitmodules` file (so everyone else also tracks it), or just in your local `.git/config` file.
 Let's set it in the `.gitmodules` file:
 
 [source,console]
@@ -418,7 +418,7 @@ no changes added to commit (use "git add" and/or "git commit -a")
 By default, the `git pull` command recursively fetches submodules changes, as we can see in the output of the first command above.
 However, it does not *update* the submodules.
 This is shown by the output of the `git status` command, which shows the submodule is "`modified`", and has "`new commits`".
-What's more, the brackets showing the new commits point left (<), indicating that these commits are recorded in MainProject but are not present in the local DbConnector checkout.
+What's more, the brackets showing the new commits point left (<), indicating that these commits are recorded in MainProject but are not present in the local `DbConnector` checkout.
 To finalize the update, you need to run `git submodule update`:
 
 [source,console]
@@ -436,7 +436,7 @@ Note that to be on the safe side, you should run `git submodule update` with the
 
 If you want to automate this process, you can add the `--recurse-submodules` flag to the `git pull` command (since Git 2.14).
 This will make Git run `git submodule update` right after the pull, putting the submodules in the correct state.
-Moreover, if you want to make Git always pull with `--recurse-submodules`, you can set the configuration option `submodule.recurse` to true (this works for `git pull` since Git 2.15).
+Moreover, if you want to make Git always pull with `--recurse-submodules`, you can set the configuration option `submodule.recurse` to `true` (this works for `git pull` since Git 2.15).
 This option will make Git use the `--recurse-submodules` flag for all commands that support it (except `clone`).
 
 There is a special situation that can happen when pulling superproject updates: it could be that the upstream repository has changed the URL of the submodule in the `.gitmodules` file in one of the commits you pull.
@@ -499,7 +499,7 @@ Fast-forward
 Submodule path 'DbConnector': merged in '92c7337b30ef9e0893e758dac2459d07362ab5ea'
 ----
 
-If we go into the DbConnector directory, we have the new changes already merged into our local `stable` branch.
+If we go into the `DbConnector` directory, we have the new changes already merged into our local `stable` branch.
 Now let's see what happens when we make our own local change to the library and someone else pushes another change to the upstream at the same time.
 
 [source,console]
@@ -532,7 +532,7 @@ Submodule path 'DbConnector': checked out '5d60ef9bbebf5a0c1c1050f242ceeb54ad58d
 
 If this happens, don't worry, you can simply go back into the directory and check out your branch again (which will still contain your work) and merge or rebase `origin/stable` (or whatever remote branch you want) manually.
 
-If you haven't committed your changes in your submodule and you run a submodule update that would cause issues, Git will fetch the changes but not overwrite unsaved work in your submodule directory.
+If you haven't committed your changes in your submodule and you run a `submodule update` that would cause issues, Git will fetch the changes but not overwrite unsaved work in your submodule directory.
 
 [source,console]
 ----
@@ -632,7 +632,7 @@ To https://github.com/chaconinc/MainProject
    3d6d338..9a377d1  master -> master
 ----
 
-As you can see there, Git went into the DbConnector module and pushed it before pushing the main project.
+As you can see there, Git went into the `DbConnector` module and pushed it before pushing the main project.
 If that submodule push fails for some reason, the main project push will also fail.
 You can make this behavior the default by doing `git config push.recurseSubmodules on-demand`.