Merge pull request #589 from hedrok/small-fixes

Small fixes

Author: ben

README.asc

@@ -44,7 +44,8 @@ This uses the `asciidoctor`, `asciidoctor-pdf` and `asciidoctor-epub` projects.
 
 Before signaling an issue, please check that there isn't already a similar one in the bug tracking system.
 
-Also, if this issue has been spotted on the git-scm.com site, please cross-check that it is still present in the pdf version. The issue may have already been corrected, but the changes have not been deployed yet.
+Also, if this issue has been spotted on the git-scm.com site, please cross-check that it is still present in the pdf version.
+The issue may have already been corrected, but the changes have not been deployed yet.
 
 == Contributing
 

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

@@ -273,7 +273,7 @@ In <<limit_options>> we'll list these and a few other common options for your re
 | `-S`                  | Only show commits adding or removing code matching the string
 |================================
 
-For example, if you want to see which commits modifying test files in the Git source code history are merged and were committed by Junio Hamano in the month of October 2008, you can run something like this:(((log filtering)))
+For example, if you want to see which commits modifying test files in the Git source code history were committed by Junio Hamano in the month of October 2008 and are not merge commits, you can run something like this:(((log filtering)))
 
 [source,console]
 ----

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

@@ -302,8 +302,8 @@ Each developer has committed a few times and merged each other's work successful
 image::images/small-team-7.png[Jessica's history after pushing all changes back to the server.]
 
 That is one of the simplest workflows.
-You work for a while, generally in a topic branch, and merge into your master branch when it's ready to be integrated.
-When you want to share that work, you fetch and merge your master from `origin/master` if it has changed, and finally push to the `master` branch on the server.
+You work for a while, generally in a topic branch, and merge into your `master` branch when it's ready to be integrated.
+When you want to share that work, you fetch and merge your `master` from `origin/master` if it has changed, and finally push to the `master` branch on the server.
 The general sequence is something like this:
 
 .General sequence of events for a simple multiple-developer Git workflow.

book/06-github/sections/5-scripting.asc

@@ -112,7 +112,8 @@ For more information on how to write webhooks and all the different event types
 ==== The GitHub API
 
 (((GitHub, API)))
-Services and hooks give you a way to receive push notifications about events that happen on your repositories, but what if you need more information about these events? What if you need to automate something like adding collaborators or labeling issues?
+Services and hooks give you a way to receive push notifications about events that happen on your repositories, but what if you need more information about these events?
+What if you need to automate something like adding collaborators or labeling issues?
 
 This is where the GitHub API comes in handy.
 GitHub has tons of API endpoints for doing nearly anything you can do on the website in an automated fashion.

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

@@ -374,7 +374,8 @@ So now let's go through an example of making changes to the submodule at the sam
 
 So far, when we've run the `git submodule update` command to fetch changes from the submodule repositories, Git would get the changes and update the files in the subdirectory but will leave the sub-repository in what's called a ``detached HEAD'' state.
 This means that there is no local working branch (like ``master'', for example) tracking changes.
-With no working branch tracking changes, that means even if you commit changes to the submodule, those changes will quite possibly be lost the next time you run `git submodule update`. You have to do some extra steps if you want changes in a submodule to be tracked.
+With no working branch tracking changes, that means even if you commit changes to the submodule, those changes will quite possibly be lost the next time you run `git submodule update`.
+You have to do some extra steps if you want changes in a submodule to be tracked.
 
 In order to set up your submodule to be easier to go in and hack on, you need do two things.
 You need to go into each submodule and check out a branch to work on.

book/08-customizing-git/sections/policy.asc

@@ -167,8 +167,7 @@ On the ACL file you looked at earlier, this `get_acl_access_data` method returns
 
 Now that you have the permissions sorted out, you need to determine what paths the commits being pushed have modified, so you can make sure the user who's pushing has access to all of them.
 
-You can pretty easily see what files have been modified in a single commit with the `--name-only` option to the `git log` command 
-(mentioned briefly in <<_git_basics_chapter>>):
+You can pretty easily see what files have been modified in a single commit with the `--name-only` option to the `git log` command (mentioned briefly in <<_git_basics_chapter>>):
 
 [source,console]
 ----
@@ -428,7 +427,9 @@ target_shas.each do |sha|
   end
 end
 ----
-This script uses a syntax that wasn't covered in <<_revision_selection>>. You get a list of commits that have already been pushed up by running this:
+
+This script uses a syntax that wasn't covered in <<_revision_selection>>.
+You get a list of commits that have already been pushed up by running this:
 
 [source,ruby]
 ----

book/09-git-and-other-scms/sections/import-svn.asc

@@ -90,11 +90,16 @@ $ cp -Rf .git/refs/remotes/origin/* .git/refs/heads/
 $ rm -Rf .git/refs/remotes/origin
 ----
 
-It may happen that you'll see some extra branches which are suffixed by `@xxx` (where xxx is a number), while in Subversion you only see one branch. This is actually a Subversion feature called "peg-revisions", which is something that Git simply has no syntactical counterpart for. Hence, `git svn` simply adds the svn version number to the branch name just in the same way as you would have written it in svn to address the peg-revision of that branch. If you do not care anymore about the peg-revisions, simply remove them using `git branch -d`.
+It may happen that you'll see some extra branches which are suffixed by `@xxx` (where xxx is a number), while in Subversion you only see one branch.
+This is actually a Subversion feature called ``peg-revisions'', which is something that Git simply has no syntactical counterpart for.
+Hence, `git svn` simply adds the svn version number to the branch name just in the same way as you would have written it in svn to address the peg-revision of that branch.
+If you do not care anymore about the peg-revisions, simply remove them using `git branch -d`.
 
 Now all the old branches are real Git branches and all the old tags are real Git tags.
 
-There's one last thing to clean up. Unfortunately, `git svn` creates an extra branch named `trunk`, which maps to Subversion's default branch, but the `trunk` ref points to the same place as `master`. Since `master` is more idiomatically Git, here's how to remove the extra branch:
+There's one last thing to clean up.
+Unfortunately, `git svn` creates an extra branch named `trunk`, which maps to Subversion's default branch, but the `trunk` ref points to the same place as `master`.
+Since `master` is more idiomatically Git, here's how to remove the extra branch:
 
 [source,console]
 ----