Merge pull request #753 from sivaraam/chap-7-changes

Changes for chapter 7

Author: ben

book/07-git-tools/sections/revision-selection.asc

@@ -82,7 +82,8 @@ That’s 1,200 times the number of grains of sand on the earth.
 
 Here’s an example to give you an idea of what it would take to get a SHA-1 collision.
 If all 6.5 billion humans on Earth were programming, and every second, each one was producing code that was the equivalent of the entire Linux kernel history (3.6 million Git objects) and pushing it into one enormous Git repository, it would take roughly 2 years until that repository contained enough objects to have a 50% probability of a single SHA-1 object collision.
-A higher probability exists that every member of your programming team will be attacked and killed by wolves in unrelated incidents on the same night.
+Thus, a SHA-1 collision is less likely than every member of your programming team being attacked and killed by wolves in unrelated incidents on the same night.
+
 ====
 
 [[_branch_references]]
@@ -120,7 +121,7 @@ You can see your reflog by using `git reflog`:
 ----
 $ git reflog
 734713b HEAD@{0}: commit: fixed refs handling, added gc auto, updated
-d921970 HEAD@{1}: merge phedders/rdocs: Merge made by recursive.
+d921970 HEAD@{1}: merge phedders/rdocs: Merge made by the 'recursive' stategy.
 1c002dd HEAD@{2}: commit: added some blame and merge stuff
 1c36188 HEAD@{3}: rebase -i (squash): updating HEAD
 95df984 HEAD@{4}: commit: # This is a combination of two commits.
@@ -130,7 +131,7 @@ d921970 HEAD@{1}: merge phedders/rdocs: Merge made by recursive.
 
 Every time your branch tip is updated for any reason, Git stores that information for you in this temporary history.
 And you can specify older commits with this data, as well.
-If you want to see the fifth prior value of the HEAD of your repository, you can use the `@{n}` reference that you see in the reflog output:
+If you want to see the fifth prior value of the HEAD of your repository, you can use the `@{5}` reference that you see in the reflog output:
 
 [source,console]
 ----
@@ -275,7 +276,7 @@ image::images/double-dot.png[Example history for range selection.]
 
 You want to see what is in your experiment branch that hasn’t yet been merged into your master branch.
 You can ask Git to show you a log of just those commits with `master..experiment` – that means ``all commits reachable by experiment that aren’t reachable by master.''
-For the sake of brevity and clarity in these examples, I’ll use the letters of the commit objects from the diagram in place of the actual log output in the order that they would display:
+For the sake of brevity and clarity in these examples, the letters of the commit objects from the diagram are used in place of the actual log output in the order that they would display:
 
 [source,console]
 ----

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

@@ -25,7 +25,7 @@ That drops you into your text editor, which has your last commit message in it,
 When you save and close the editor, the editor writes a new commit containing that message and makes it your new last commit.
 
 If you’ve committed and then you want to change the snapshot you committed by adding or changing files, possibly because you forgot to add a newly created file when you originally committed, the process works basically the same way.
-You stage the changes you want by editing a file and running `git add` on it or `git rm` to a tracked file, and the subsequent `git commit --amend` takes your current staging area and makes it the snapshot for the new commit.
+You stage the changes you want by editing a file and running `git add` on it or `git rm` to a tracked file, and the subsequent `git commit --amend` takes your current staging area and adds it to the last snapshot making it the snapshot of the last commit.
 
 You need to be careful with this technique because amending changes the SHA-1 of the commit.
 It’s like a very small rebase – don’t amend your last commit if you’ve already pushed it.

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

@@ -95,11 +95,11 @@ As we saw in the above example, we looked for terms in an older version of the G
 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.
+If we want to find out for example when the `ZLIB_BUF_MAX` constant was originally introduced, we can use the `-S` option to tell Git to only show us the commits that either added or removed that string.
 
 [source,console]
 ----
-$ git log -SZLIB_BUF_MAX --oneline
+$ git log -S ZLIB_BUF_MAX --oneline
 e01503b zlib: allow feeding more than 4GB in one go
 ef49a7a zlib: zlib can only process 4GB at a time
 ----
@@ -111,8 +111,7 @@ If you need to be more specific, you can provide a regular expression to search
 ===== Line Log Search
 
 Another fairly advanced log search that is insanely useful is the line history search.
-This is a fairly recent addition and not very well known, but it can be really helpful.
-It is called with the `-L` option to `git log` and will show you the history of a function or line of code in your codebase.
+Simply run `git log` with the `-L` option, and it will show you the history of a function or line of code in your codebase.
 
 For example, if we wanted to see every change made to the function `git_deflate_bound` in the `zlib.c` file, we could run `git log -L :git_deflate_bound:zlib.c`.
 This will try to figure out what the bounds of that function are and then look through the history and show us every change that was made to the function as a series of patches back to when the function was first created.

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

@@ -179,7 +179,7 @@ Fast-forward
  1 file changed, 2 insertions(+)
 ----
 
-You can also use the `-S` option with the `git merge` command itself to sign the resulting merge commit itself.
+You can also use the `-S` option with the `git merge` command to sign the resulting merge commit itself.
 The following example both verifies that every commit in the branch to be merged is signed and furthermore signs the resulting merge commit.
 
 [source,console]

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

@@ -79,7 +79,8 @@ no changes added to commit (use "git add" and/or "git commit -a")
 ----
 
 You can see that Git re-modifies the files you reverted when you saved the stash.
-In this case, you had a clean working directory when you tried to apply the stash, and you tried to apply it on the same branch you saved it from; but having a clean working directory and applying it on the same branch aren’t necessary to successfully apply a stash.
+In this case, you had a clean working directory when you tried to apply the stash, and you tried to apply it on the same branch you saved it from.
+Having a clean working directory and applying it on the same branch aren’t necessary to successfully apply a stash.
 You can save a stash on one branch, switch to another branch later, and try to reapply the changes.
 You can also have modified and uncommitted files in your working directory when you apply a stash – Git gives you merge conflicts if anything no longer applies cleanly.
 
@@ -188,7 +189,7 @@ Saved working directory and index state WIP on master: 1b65b17 added the index f
 
 If you stash some work, leave it there for a while, and continue on the branch from which you stashed the work, you may have a problem reapplying the work.
 If the apply tries to modify a file that you’ve since modified, you’ll get a merge conflict and will have to try to resolve it.
-If you want an easier way to test the stashed changes again, you can run `git stash branch`, which creates a new branch for you, checks out the commit you were on when you stashed your work, reapplies your work there, and then drops the stash if it applies successfully:
+If you want an easier way to test the stashed changes again, you can run `git stash branch <branch-name>`, which creates a new branch for you with the given `branch-name`, checks out the commit you were on when you stashed your work, reapplies your work there, and then drops the stash if it applies successfully:
 
 [source,console]
 ----