new lines

Author: noisy

README.asc

@@ -6,19 +6,24 @@ You can find this book online at: http://git-scm.com/book
 
 Like the first edition, the second edition of Pro Git is open source under a Creative Commons license.
 
-A couple of things have changed since open sourcing the first edition. For one, we've moved from Markdown to the amazing Asciidoc format for the text of the book. We've also moved to using O'Reilly's https://atlas.oreilly.com[Atlas platform] for generating continuous builds of the book so all major formats are always available in every language.
+A couple of things have changed since open sourcing the first edition.
+For one, we've moved from Markdown to the amazing Asciidoc format for the text of the book.
+We've also moved to using O'Reilly's https://atlas.oreilly.com[Atlas platform] for generating continuous builds of the book so all major formats are always available in every language.
 
-We've also moved to keeping the translations in separate repositories rather than subdirectories of the English repository. See link:CONTRIBUTING.md[the Contributing document] for more information.
+We've also moved to keeping the translations in separate repositories rather than subdirectories of the English repository.
+See link:CONTRIBUTING.md[the Contributing document] for more information.
 
 == How To Generate the Book
 
 There are two ways to generate e-book content from this source code.
 
-The easiest way is simply to let us do it. A robot is standing by to look for new work on the main branch and automatically build it for everyone.
+The easiest way is simply to let us do it.
+A robot is standing by to look for new work on the main branch and automatically build it for everyone.
 
 You can find the current builds on http://git-scm.com/book[] and more information about the builds available at https://progit.org[].
 
-The other way to generate e-book files is to do so manually with Asciidoctor. If you run the following you _may_ actually get HTML, Epub, Mobi and PDF output files:
+The other way to generate e-book files is to do so manually with Asciidoctor.
+If you run the following you _may_ actually get HTML, Epub, Mobi and PDF output files:
 
 ----
 $ bundle install

TRANSLATION_NOTES.asc

@@ -1,9 +1,11 @@
 == Translation Notes
 
-After forking this repository to translate the work, this file is where the notes for coordinating the translation work would go. Things like standardizing on words and expressions so that the work is consistent or notes on how the contributing process is to be handled.
+After forking this repository to translate the work, this file is where the notes for coordinating the translation work would go.
+Things like standardizing on words and expressions so that the work is consistent or notes on how the contributing process is to be handled.
 
 As a translation maintainer, also feel free to modify or completely rewrite the README file to contain instructions specific to your translation.
 
 === Translation Status
 
-As the work is translated, please update the `status.json` file to indicate the rough percentage complete each file is. This will be shown on various pages to let people know how much work is left to be done.
+As the work is translated, please update the `status.json` file to indicate the rough percentage complete each file is.
+This will be shown on various pages to let people know how much work is left to be done.

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

@@ -48,7 +48,8 @@ $ git config --global core.editor emacs
 
 [WARNING]
 ====
-Vim and Emacs are popular text editors often used by developers on Unix based systems like Linux and Mac. If you are not familiar with either of these editors or are on a Windows system, you may need to search for instructions for how to set up your favorite editor with Git.
+Vim and Emacs are popular text editors often used by developers on Unix based systems like Linux and Mac.
+If you are not familiar with either of these editors or are on a Windows system, you may need to search for instructions for how to set up your favorite editor with Git.
 If you don't set an editor like this and you don't know what Vim or Emacs are, you will likely get into a really confusing state when they are launched.
 ====
 

book/01-introduction/sections/installing.asc

@@ -6,7 +6,9 @@ You can either install it as a package or via another installer, or download the
 
 [NOTE]
 ====
-This book was written using Git version *2.0.0*. Though most of the commands we use should work even in ancient versions of Git, some of them might not or might act slightly differently if you're using an older version. Since Git is quite excellent at preserving backwards compatibility, any version after 2.0 should work just fine.
+This book was written using Git version *2.0.0*.
+Though most of the commands we use should work even in ancient versions of Git, some of them might not or might act slightly differently if you're using an older version.
+Since Git is quite excellent at preserving backwards compatibility, any version after 2.0 should work just fine.
 ====
 
 ==== Installing on Linux

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

@@ -56,7 +56,8 @@ origin    [email protected]:mojombo/grit.git (fetch)
 origin    [email protected]:mojombo/grit.git (push)
 ----
 
-This means we can pull contributions from any of these users pretty easily. We may additionally have permission to push to one or more of these, though we can't tell that here.
+This means we can pull contributions from any of these users pretty easily.
+We may additionally have permission to push to one or more of these, though we can't tell that here.
 
 Notice that these remotes use a variety of protocols; we'll cover more about this in <<_git_on_the_server>>.
 

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

@@ -79,10 +79,12 @@ The `CONTRIBUTING.md` file is modified but once again unstaged.
 
 [NOTE]
 =====
-While `git reset` _can_ be a dangerous command if you call it with `--hard`, in this instance the file in your working directory is not touched. Calling `git reset` without an option is not dangerous - it only touches your staging area.
+While `git reset` _can_ be a dangerous command if you call it with `--hard`, in this instance the file in your working directory is not touched.
+Calling `git reset` without an option is not dangerous - it only touches your staging area.
 =====
 
-For now this magic invocation is all you need to know about the `git reset` command. We'll go into much more detail about what `reset` does and how to master it to do really interesting things in <<_git_reset>>.
+For now this magic invocation is all you need to know about the `git reset` command.
+We'll go into much more detail about what `reset` does and how to master it to do really interesting things in <<_git_reset>>.
 
 ==== Unmodifying a Modified File
 
@@ -119,7 +121,8 @@ You can see that the changes have been reverted.
 
 [IMPORTANT]
 =====
-It's important to understand that `git checkout -- [file]` is a dangerous command. Any changes you made to that file are gone – you just copied another file over it.
+It's important to understand that `git checkout -- [file]` is a dangerous command.
+Any changes you made to that file are gone – you just copied another file over it.
 Don't ever use this command unless you absolutely know that you don't want the file.
 =====
 

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

@@ -245,7 +245,8 @@ You can also filter the list to commits that match some search criteria.
 The `--author` option allows you to filter on a specific author, and the `--grep` option lets you search for keywords in the commit messages.
 (Note that if you want to specify both author and grep options, you have to add `--all-match` or the command will match commits with either.)
 
-Another really helpful filter is the `-S` option which takes a string and only shows the commits that introduced a change to the code that added or removed 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:
+Another really helpful filter is the `-S` option which takes a string and only shows the commits that introduced a change to the code that added or removed 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/nutshell.asc

@@ -74,7 +74,8 @@ The `git branch` command only _created_ a new branch – it didn't switch to tha
 .HEAD pointing to a branch
 image::images/head-to-master.png[HEAD pointing to a branch.]
 
-You can easily see this by running a simple `git log` command that shows you where the branch pointers are pointing. This option is called `--decorate`.
+You can easily see this by running a simple `git log` command that shows you where the branch pointers are pointing.
+This option is called `--decorate`.
 
 [source,console]
 ----

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

@@ -179,9 +179,11 @@ It's pretty safe to assume that the other developer doesn't want `C4` and `C6` t
 [[_rebase_rebase]]
 ==== Rebase When You Rebase
 
-If you *do* find yourself in a situation like this, Git has some further magic that might help you out. If someone on your team force pushes changes that overwrite work that you've based work on, your challenge is to figure out what is yours and what they've rewritten.
+If you *do* find yourself in a situation like this, Git has some further magic that might help you out.
+If someone on your team force pushes changes that overwrite work that you've based work on, your challenge is to figure out what is yours and what they've rewritten.
 
-It turns out that in addition to the commit SHA-1 checksum, Git also calculates a checksum that is based just on the patch introduced with the commit. This is called a ``patch-id''.
+It turns out that in addition to the commit SHA-1 checksum, Git also calculates a checksum that is based just on the patch introduced with the commit.
+This is called a ``patch-id''.
 
 If you pull down work that was rewritten and rebase it on top of the new commits from your partner, Git can often successfully figure out what is uniquely yours and apply them back on top of the new branch.
 
@@ -198,9 +200,11 @@ So instead of the result we see in <<_merge_rebase_work>>, we would end up with
 .Rebase on top of force-pushed rebase work.
 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).
+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).
 
-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.
+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.
 
 If you are using `git pull` and want to make `--rebase` the default, you can set the `pull.rebase` config value with something like `git config --global pull.rebase true`.
 

book/03-git-branching/sections/remote-branches.asc

@@ -22,7 +22,9 @@ Git also gives you your own local `master` branch starting at the same place as
 [NOTE]
 .``origin'' is not special
 ====
-Just like the branch name ``master'' does not have any special meaning in Git, neither does ``origin''. While ``master'' is the default name for a starting branch when you run `git init` which is the only reason it's widely used, ``origin'' is the default name for a remote when you run `git clone`. If you run `git clone -o booyah` instead, then you will have `booyah/master` as your default remote branch.(((origin)))
+Just like the branch name ``master'' does not have any special meaning in Git, neither does ``origin''.
+While ``master'' is the default name for a starting branch when you run `git init` which is the only reason it's widely used, ``origin'' is the default name for a remote when you run `git clone`.
+If you run `git clone -o booyah` instead, then you will have `booyah/master` as your default remote branch.(((origin)))
 ====
 
 .Server and local repositories after cloning
@@ -87,9 +89,11 @@ If you didn't want it to be called `serverfix` on the remote, you could instead
 [NOTE]
 .Don't type your password every time
 ====
-If you're using an HTTPS URL to push over, the Git server will ask you for your username and password for authentication. By default it will prompt you on the terminal for this information so the server can tell if you're allowed to push.
+If you're using an HTTPS URL to push over, the Git server will ask you for your username and password for authentication.
+By default it will prompt you on the terminal for this information so the server can tell if you're allowed to push.
 
-If you don't want to type it every single time you push, you can set up a ``credential cache''. The simplest is just to keep it in memory for a few minutes, which you can easily set up by running `git config --global credential.helper cache`.
+If you don't want to type it every single time you push, you can set up a ``credential cache''.
+The simplest is just to keep it in memory for a few minutes, which you can easily set up by running `git config --global credential.helper cache`.
 
 For more information on the various credential caching options available, see <<_credential_caching>>.
 ====
@@ -164,10 +168,12 @@ Branch serverfix set up to track remote branch serverfix from origin.
 [NOTE]
 .Upstream shorthand
 ====
-When you have a tracking branch set up, you can reference it with the `@{upstream}` or `@{u}` shorthand. So if you're on the `master` branch and it's tracking `origin/master`, you can say something like `git merge @{u}` instead of `git merge origin/master` if you wish.(((+++@{u}+++)))(((+++@{upstream}+++)))
+When you have a tracking branch set up, you can reference it with the `@{upstream}` or `@{u}` shorthand.
+So if you're on the `master` branch and it's tracking `origin/master`, you can say something like `git merge @{u}` instead of `git merge origin/master` if you wish.(((+++@{u}+++)))(((+++@{upstream}+++)))
 ====
 
-If you want to see what tracking branches you have set up, you can use the `-vv` option to `git branch`. This will list out your local branches with more information including what each branch is tracking and if your local branch is ahead, behind or both.
+If you want to see what tracking branches you have set up, you can use the `-vv` option to `git branch`.
+This will list out your local branches with more information including what each branch is tracking and if your local branch is ahead, behind or both.
 
 [source,console]
 ----
@@ -178,9 +184,15 @@ $ git branch -vv
   testing   5ea463a trying something new
 ----
 
-So here we can see that our `iss53` branch is tracking `origin/iss53` and is ``ahead'' by two, meaning that we have two commits locally that are not pushed to the server. We can also see that our `master` branch is tracking `origin/master` and is up to date. Next we can see that our `serverfix` branch is tracking the `server-fix-good` branch on our `teamone` server and is ahead by three and behind by one, meaning that there is one commit on the server we haven't merged in yet and three commits locally that we haven't pushed. Finally we can see that our `testing` branch is not tracking any remote branch.
+So here we can see that our `iss53` branch is tracking `origin/iss53` and is ``ahead'' by two, meaning that we have two commits locally that are not pushed to the server.
+We can also see that our `master` branch is tracking `origin/master` and is up to date.
+Next we can see that our `serverfix` branch is tracking the `server-fix-good` branch on our `teamone` server and is ahead by three and behind by one, meaning that there is one commit on the server we haven't merged in yet and three commits locally that we haven't pushed.
+Finally we can see that our `testing` branch is not tracking any remote branch.
 
-It's important to note that these numbers are only since the last time you fetched from each server. This command does not reach out to the servers, it's telling you about what it has cached from these servers locally. If you want totally up to date ahead and behind numbers, you'll need to fetch from all your remotes right before running this. You could do that like this: `$ git fetch --all; git branch -vv`
+It's important to note that these numbers are only since the last time you fetched from each server.
+This command does not reach out to the servers, it's telling you about what it has cached from these servers locally.
+If you want totally up to date ahead and behind numbers, you'll need to fetch from all your remotes right before running this.
+You could do that like this: `$ git fetch --all; git branch -vv`
 
 ==== Pulling
 
@@ -207,4 +219,5 @@ To https://github.com/schacon/simplegit
  - [deleted]         serverfix
 ----
 
-Basically all this does is remove the pointer from the server. The Git server will generally keep the data there for a while until a garbage collection runs, so if it was accidentally deleted, it's often easy to recover.
+Basically all this does is remove the pointer from the server.
+The Git server will generally keep the data there for a while until a garbage collection runs, so if it was accidentally deleted, it's often easy to recover.

book/04-git-server/sections/git-daemon.asc

@@ -1,7 +1,9 @@
 === Git Daemon
 
 (((serving repositories, git protocol)))
-Next we'll set up a daemon serving repositories over the ``Git'' protocol. This is common choice for fast, unauthenticated access to your Git data. Remember that since it's not an authenticated service, anything you serve over this protocol is public within its network.
+Next we'll set up a daemon serving repositories over the ``Git'' protocol.
+This is common choice for fast, unauthenticated access to your Git data.
+Remember that since it's not an authenticated service, anything you serve over this protocol is public within its network.
 
 If you're running this on a server outside your firewall, it should only be used for projects that are publicly visible to the world.
 If the server you're running it on is inside your firewall, you might use it for projects that a large number of people or computers (continuous integration or build servers) have read-only access to, when you don't want to have to add an SSH key for each.
@@ -53,7 +55,8 @@ initctl start local-git-daemon
 
 On other systems, you may want to use `xinetd`, a script in your `sysvinit` system, or something else – as long as you get that command daemonized and watched somehow.
 
-Next, you have to tell Git which repositories to allow unauthenticated Git server-based access to. You can do this in each repository by creating a file named `git-daemon-export-ok`.
+Next, you have to tell Git which repositories to allow unauthenticated Git server-based access to.
+You can do this in each repository by creating a file named `git-daemon-export-ok`.
 
 [source,console]
 ----