From 739f7c35f3d723da775c80c6afbd167b8b4bf4b4 Mon Sep 17 00:00:00 2001 From: Kaartic Sivaraam Date: Thu, 18 May 2017 14:50:18 +0530 Subject: [PATCH 01/11] Corrected sentence about SHA-1 collision Fixes: #700 --- book/07-git-tools/sections/revision-selection.asc | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/book/07-git-tools/sections/revision-selection.asc b/book/07-git-tools/sections/revision-selection.asc index a141bd10e..2d1cefdf9 100644 --- a/book/07-git-tools/sections/revision-selection.asc +++ b/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]] From 4d54dab25f468f1288fb05637074f4202797ee2f Mon Sep 17 00:00:00 2001 From: Kaartic Sivaraam Date: Thu, 18 May 2017 14:54:56 +0530 Subject: [PATCH 02/11] Corrected reflog example The sentence wasn't consistent and was corrected. --- book/07-git-tools/sections/revision-selection.asc | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/book/07-git-tools/sections/revision-selection.asc b/book/07-git-tools/sections/revision-selection.asc index 2d1cefdf9..39ba2a668 100644 --- a/book/07-git-tools/sections/revision-selection.asc +++ b/book/07-git-tools/sections/revision-selection.asc @@ -131,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] ---- From 17e9c644a8366eb5ded9ed67ea5362105c3601fa Mon Sep 17 00:00:00 2001 From: Kaartic Sivaraam Date: Thu, 18 May 2017 14:57:31 +0530 Subject: [PATCH 03/11] Corrected reflog output snippet The reflog output wasn't reflecting the new message shown by git for merges --- book/07-git-tools/sections/revision-selection.asc | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/book/07-git-tools/sections/revision-selection.asc b/book/07-git-tools/sections/revision-selection.asc index 39ba2a668..ab3427628 100644 --- a/book/07-git-tools/sections/revision-selection.asc +++ b/book/07-git-tools/sections/revision-selection.asc @@ -121,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. From e3ad20f17c5707f9b9979b614d26234f065ed03c Mon Sep 17 00:00:00 2001 From: Kaartic Sivaraam Date: Thu, 18 May 2017 15:03:16 +0530 Subject: [PATCH 04/11] Fixed self reference in a sentence --- book/07-git-tools/sections/revision-selection.asc | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/book/07-git-tools/sections/revision-selection.asc b/book/07-git-tools/sections/revision-selection.asc index ab3427628..887d40ac9 100644 --- a/book/07-git-tools/sections/revision-selection.asc +++ b/book/07-git-tools/sections/revision-selection.asc @@ -276,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] ---- From 6ac09258e0464ea8c6ed2d4b5d1c83babc2f0f2f Mon Sep 17 00:00:00 2001 From: Kaartic Sivaraam Date: Thu, 18 May 2017 15:08:05 +0530 Subject: [PATCH 05/11] Split a long sentence --- book/07-git-tools/sections/stashing-cleaning.asc | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/book/07-git-tools/sections/stashing-cleaning.asc b/book/07-git-tools/sections/stashing-cleaning.asc index 8df90b10a..cf706bb28 100644 --- a/book/07-git-tools/sections/stashing-cleaning.asc +++ b/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. From 8ad19f067b90d2b69ba86c72ec973df9a0fa1ed4 Mon Sep 17 00:00:00 2001 From: Kaartic Sivaraam Date: Thu, 18 May 2017 15:11:17 +0530 Subject: [PATCH 06/11] Corrected the example command to be more specific Made the example command reflect the command that needs to be used by the user. --- book/07-git-tools/sections/stashing-cleaning.asc | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/book/07-git-tools/sections/stashing-cleaning.asc b/book/07-git-tools/sections/stashing-cleaning.asc index cf706bb28..9b944adc5 100644 --- a/book/07-git-tools/sections/stashing-cleaning.asc +++ b/book/07-git-tools/sections/stashing-cleaning.asc @@ -189,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 `, 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] ---- From 990f59a96ab1241123bbfb6db0135d9ef4ef5395 Mon Sep 17 00:00:00 2001 From: Kaartic Sivaraam Date: Sat, 20 May 2017 15:41:48 +0530 Subject: [PATCH 07/11] Removed the redundant word in a line --- book/07-git-tools/sections/signing.asc | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/book/07-git-tools/sections/signing.asc b/book/07-git-tools/sections/signing.asc index faedd85f7..b56dfbcf8 100644 --- a/book/07-git-tools/sections/signing.asc +++ b/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] From 69dcd290f65a7e52f9242d106e9a07f9ecaa4353 Mon Sep 17 00:00:00 2001 From: Kaartic Sivaraam Date: Sat, 20 May 2017 15:51:07 +0530 Subject: [PATCH 08/11] Improved a sentence A sentence thatput the main point at the end didn't seem nice and thus the point was specified earlier followed by it's outcome A sample code was made better as it seems to have the same effect --- book/07-git-tools/sections/searching.asc | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/book/07-git-tools/sections/searching.asc b/book/07-git-tools/sections/searching.asc index 3d7280512..ce6a92547 100644 --- a/book/07-git-tools/sections/searching.asc +++ b/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 ---- From b7c94eb4e6b8c423464fd2ad05fdb58fb062a6cd Mon Sep 17 00:00:00 2001 From: Kaartic Sivaraam Date: Sat, 20 May 2017 15:56:30 +0530 Subject: [PATCH 09/11] Made a few changes to improve readability * Removed time related words * Split a sentence to improve readability --- book/07-git-tools/sections/searching.asc | 5 +++-- 1 file changed, 3 insertions(+), 2 deletions(-) diff --git a/book/07-git-tools/sections/searching.asc b/book/07-git-tools/sections/searching.asc index ce6a92547..f1ec1f7d3 100644 --- a/book/07-git-tools/sections/searching.asc +++ b/book/07-git-tools/sections/searching.asc @@ -111,8 +111,9 @@ 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. +This can be really helpful. +It is called with the `-L` option to `git log`. +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. From 6b57805e145d3b5677c150478e4636588cafd892 Mon Sep 17 00:00:00 2001 From: Kaartic Sivaraam Date: Mon, 19 Jun 2017 19:12:44 +0530 Subject: [PATCH 10/11] Merge sentences and modify it as suggested by @ben The long sentences were merged into one short concise to increas readability. --- book/07-git-tools/sections/searching.asc | 4 +--- 1 file changed, 1 insertion(+), 3 deletions(-) diff --git a/book/07-git-tools/sections/searching.asc b/book/07-git-tools/sections/searching.asc index f1ec1f7d3..c56f216f2 100644 --- a/book/07-git-tools/sections/searching.asc +++ b/book/07-git-tools/sections/searching.asc @@ -111,9 +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 can be really helpful. -It is called with the `-L` option to `git log`. -It 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. From 6f2cdd07f1649c10ba5e0f62e12b6f9a98971de0 Mon Sep 17 00:00:00 2001 From: Kaartic Sivaraam Date: Tue, 20 Jun 2017 08:21:32 +0530 Subject: [PATCH 11/11] Make the sentence abuot amending to be more accurate --- book/07-git-tools/sections/rewriting-history.asc | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/book/07-git-tools/sections/rewriting-history.asc b/book/07-git-tools/sections/rewriting-history.asc index 9819e0900..2f1d2d232 100644 --- a/book/07-git-tools/sections/rewriting-history.asc +++ b/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.