Chapters 10-13: make copy editor corrections.

10-GitHubPullRequests.adoc

@@ -5,7 +5,6 @@ GitHub provides more than just Git hosting that you can `git push` to and `git f
 
 Two of these features are _pull requests_ and _forks_. In this chapter you'll learn about GitHub's pull requests by learning about the following topics:
 
-// BEN: usual manning style is just "In this chapter" and then the bullets
 * How to make pull requests from branches on the same repository
 * How to make pull requests from branches a forked repository
 * How to interact with forks and pull requests from the command-line

11-HostingARepository.adoc

@@ -8,16 +8,13 @@ We saw in <<02-RemoteGit#adding-a-remote-repository-git-remote-add>> how to push
 * Provide an internal mirror of an external Git repository to allow faster transfer speeds
 * Host a Git repository on a server entirely under your own control
 
-// BEN: unclear: "sharing and viewing a repository on my machine with repositories on other machines" 
-I personally only use the commands in this chapter for basic sharing and viewing of a repository on my machine with repositories on other machines on the same network (rather than over the internet). Though we'll see more advanced tools in <<advanced-git-hosting>>, this chapter is focused on understanding the features provided by Git itself and how it works, rather than more advanced Git hosting solutions. In essence, this chapter is a guide for software engineers to understand how Git repositories can be shared and not a guide for system administrators on how set up Git servers. Unless you're an experienced system administrator, I'd advise using on an external Git hosting provider (such as GitHub) rather than running your own Git servers. We'll cover Git's repository hosting commands by learning about the following topics:
+I only use the commands in this chapter for viewing a local repository or sharing a local repository with computers on the same network (rather than over the internet). Though we'll see more advanced tools in <<advanced-git-hosting>>, this chapter is focused on understanding the features provided by Git itself and how it works, rather than more advanced Git hosting solutions. In essence, this chapter is a guide for software engineers to understand how Git repositories can be shared and not a guide for system administrators on how set up Git servers. Unless you're an experienced system administrator, I'd advise using on an external Git hosting provider (such as GitHub) rather than running your own Git servers. We'll cover Git's repository hosting commands by learning about the following topics:
 
-// BEN: usual Manning style is just "In this chapter" and then the bullets. (all the above would go below the intro bullets)
-// BEN: also, some of these bullets are a bit too long... should be no more than 8 words each
-* How to create a repository in a format used for hosting as a server
-* How to mirror an existing repository for hosting as a server
-* How to share the contents of a repository with users on the same network
-* How to display the contents of a repository in a web browser
-* How to provide more advanced Git hosting with other software
+* How to create a repository in a format for hosting a server
+* How to mirror an existing repository for hosting a server
+* How to share a repository with a local network
+* How to view a repository in a web browser
+* How to provide advanced Git hosting with other software
 
 ### Initialize a local repository in a server hosting format: git init --bare
 The Git repositories we've seen throughout this book have all had a similar structure: the working directory contains a checkout of the files in the current branch and a `.git` subdirectory which contains the repository data.
@@ -256,7 +253,6 @@ You have successfully displayed the contents of the repository in a browser..
 ### Advanced Git hosting
 In addition to the tools provided with Git you've seen in this chapter, there is a wide third-party ecosystem of Git tools that can help you share your repositories and provide a web interface to view them. There are too many and their setup is too involved for me to detail them all here. Some of the most popular options are:
 
-// BEN: we don't really do definition lists like this. we do bulleted lists with the intro term separated by an em-dash
 GitHub::
     GitHub (https://github.com) is the most widely used Git hosting, and provides many features beyond sharing and viewing Git repositories. It provides free open-source public hosting and paid private hosting. Alternatively you can pay for GitHub Enterprise (https://enterprise.github.com), which provides a hosted GitHub appliance that can be run inside your network.
 

12-CreatingACleanHistory.adoc

@@ -3,7 +3,6 @@ ifdef::env-github[:outfilesuffix: .adoc]
 
 We saw in <<01-LocalGit#viewing-history-git-log-gitk-gitx>> that a clean history can make it easier to find useful information. For a history to be clean, it should use good, well-formatted commit messages for commits which are as small as possible.
 
-// usual Manning style is just "In this chapter" and the bullets
 In this chapter you will learn how to create a clean history by learning the following topics:
 
 * How to write a good commit message
@@ -18,9 +17,6 @@ Here's an example of a good commit message format. It's strongly influenced by
 a guide written by Tim Pope, which is now at
 http://tbaggery.com/2008/04/19/a-note-about-git-commit-messages.html.
 
-// BEN: this looks like it's formatted as a listing, and I'm not sure why
-// BEN: if I were editing this, I would definitely remove all the "e.g."s but am unsure how to handle if it's supposed to be a listing with limited line length
-
 .Good commit message format
 ```
 Commits: first line is a summary (<51 characters).
@@ -36,8 +32,8 @@ the first line of the commit may get confused.
 The commit's message body can be split into multiple paragraphs which
 should be wrapped at 72 characters or fewer. The wrapping is done to
 ensure the output of tools like `git log` remains readable even when it
-adds indentation for e.g. diffs. Otherwise the commit message has no
-other limits on length; it should be as long as it needs to be to fully
+adds indentation for diffs. Otherwise the commit message has no other
+limits on length; it should be as long as it needs to be to fully
 explain the commit. While the subject might describe what the commit
 does, the body should expand on why the change was made. It should also
 use the present tense to match the tense used by commit messages
@@ -47,8 +43,8 @@ If you're using GitHub (and some other tools) then the contents of
 commit messages can contain Markdown. You may use Markdown to add some
 formatting that looks good in ASCII or rendered such as using **bold**,
 _italics_, ~~strikethrough~~, `monospace` or lists bulleted with a `*`
-or numbered with e.g. `1.`. You shouldn't go overboard with this but it
-can add some useful, basic formatting.
+or numbered with, for example `1.`. You shouldn't go overboard with
+this but it can add some useful, basic formatting.
 ```
 
 ### Building a commit from parts of files: git add --patch
@@ -191,18 +187,13 @@ As you may have noticed, throughout this book I mostly prefer to use (and theref
 We saw in <<building-a-commit-from-parts-of-files-git-add-patch>> how to build commits from parts of files from the Git command-line application, but it's a task I've found is far easier using a graphical application. In this section I'll show you how to do this with GitX or `git-gui` (which provides this functionality in a separate application).
 
 #### Graphically building a commit in GitX
-GitX provides a staging mode that also allows adding entire files or individual hunks to staging provides support for graphically staging hunks. If you click on the "Stage" in the top-right of GitX it should resemble the following:
-
-// BEN: it looks like the figure shows what happens after you click Stage, so it's not clear what "stage" is: is it a button, similar to the Unstage button in the figure?
-// BEN: we most likely should remove the quotes around "Stage" but I don't know whether it should be changed to "click Stage in the top right" or "click the Stage button"
+GitX provides a staging mode that also allows adding entire files or individual hunks to staging provides support for graphically staging hunks. If you click on the Stage hunk button in the top-right of GitX it should resemble the following:
 
 .GitX stage mode
 [[gitx-stage]]
 image::diagrams/12-GitXBeforeStage.png[]
 
-// BEN: Manning generally doesn't use code font for things like menus and buttons. Instead we just use Headline Case in a plain-text font.
-
-You can see from <<gitx-stage>> that the staging mode shows a selection of files to stage, the changes to the selected file, and allows staging of hunks or selected lines through their respective buttons. Stage the `// Git Through Praxis?` line by clicking on it and then clicking the `Stage line` button that appears on the right of that line. If you had wanted to stage all the lines in a hunk you could've clicked the Stage button at the top-right of the hunk. If you had wanted to stage all changes in a file, you could've right-clicked on the file name in the Unstaged Changes list and selected Stage Changes from the right-click menu.
+You can see from <<gitx-stage>> that the staging mode shows a selection of files to stage, the changes to the selected file, and allows staging of hunks or selected lines through their respective buttons. Stage the `// Git Through Praxis?` line by clicking on it and then clicking the Stage line button that appears on the right of that line. If you had wanted to stage all the lines in a hunk you could've clicked the Stage button at the top-right of the hunk. If you had wanted to stage all changes in a file, you could've right-clicked on the file name in the Unstaged Changes list and selected Stage Changes from the right-click menu.
 
 .GitX staged hunk
 [[gitx-staged-hunk]]

13-MergingVsRebasing.adoc

@@ -1,8 +1,6 @@
 ## Merging versus rebasing
 ifdef::env-github[:outfilesuffix: .adoc]
 
-// BEN: usual Manning style is just "In this chapter" and then the bullets
-
 In this chapter you will learn about the pros and cons of merging vs rebasing by learning the following topics:
 
 * How CMake uses a branching and merging strategy to manage contributions
@@ -127,8 +125,7 @@ For a Homebrew maintainer to merge a branch into `master`:
 
 1.  Checkout the `master` branch with `git checkout master`.
 2.  Add the forked repository and cherry-pick the commit with `git add remote username https://github.com/username/homebrew.git`, `git fetch username`, and `git merge username/branchname`. Alternatively, some maintainers (including me) use Homebrew's `brew pull` command, which pulls the contents of a pull request onto a local branch by using patch files rather than fetching from the forked repository.
-3.  Rebase, reword, and clean up the commits on `master` with `git rebase --interactive origin/master`. It's common for Homebrew maintainers to edit or squash commits and rewrite commit messages but preserve the "author" metadata so the author retains credit. Often a commit will be edited to contain a string like "Closes #123", which automatically closes the pull request numbered 123 when the commit is merged to master. This will also be covered more in chapter 11.
-// BEN: this is ch 13, so if the ref to ch 11 is correct then it should say "was" -- otherwise please fix reference
+3.  Rebase, reword, and clean up the commits on `master` with `git rebase --interactive origin/master`. It's common for Homebrew maintainers to edit or squash commits and rewrite commit messages but preserve the "author" metadata so the author retains credit. Often a commit will be edited to contain a string like "Closes #123", which automatically closes the pull request numbered 123 when the commit is merged to master. This was covered more in chapter 10.
 4.  Push the `master` branch with `git push`.
 
 ### CMake's workflow pros and cons