upto-f61c801 (8, 10)

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

@@ -180,7 +180,7 @@ index 0b013ca..ba25db5 100644
 ----
 
 //////////////////////////
-Git successfully and succinctly tells me that I added the string ``Testing: 1, 2, 3.'', which is correct.
+Git successfully and succinctly tells us that we added the string ``Testing: 1, 2, 3.'', which is correct.
 It's not perfect – formatting changes wouldn't show up here – but it certainly works.
 //////////////////////////
 `git diff` 명령의 결과를 보면 ``Testing: 1, 2, 3.'' 부분이 추가된 것을 확인할 수 있다.
@@ -254,7 +254,7 @@ Git은 먼저 체크섬을 계산하고 커밋하기 때문에 그 커밋에 대
 //////////////////////////
 First, you can inject the SHA-1 checksum of a blob into an `$Id$` field in the file automatically.
 If you set this attribute on a file or set of files, then the next time you check out that branch, Git will replace that field with the SHA-1 of the blob.
-It's important to notice that it isn't the SHA of the commit, but of the blob itself:
+It's important to notice that it isn't the SHA-1 of the commit, but of the blob itself:
 //////////////////////////
 파일 안에 `$Id$` 필드를 넣으면 Blob의 SHA-1 체크섬을 자동으로 삽입한다.
 이 필드를 파일에 넣으면 Git은 앞으로 Checkout할 때 해당 Blob의 SHA-1 값으로 교체한다.
@@ -267,9 +267,9 @@ $ echo '$Id$' > test.txt
 ----
 
 //////////////////////////
-The next time you check out this file, Git injects the SHA of the blob:
+The next time you check out this file, Git injects the SHA-1 of the blob:
 //////////////////////////
-Git은 이 파일을 Checkout할 때마다 SHA 값을 삽입해준다.
+Git은 이 파일을 Checkout할 때마다 SHA-1 값을 삽입해준다.
 
 [source,console]
 ----
@@ -281,10 +281,10 @@ $Id: 42812b7653c7b88933f8a9d6cad0ca16714b9bb3 $
 
 //////////////////////////
 However, that result is of limited use.
-If you've used keyword substitution in CVS or Subversion, you can include a datestamp – the SHA isn't all that helpful, because it's fairly random and you can't tell if one SHA is older or newer than another just by looking at them.
+If you've used keyword substitution in CVS or Subversion, you can include a datestamp – the SHA-1 isn't all that helpful, because it's fairly random and you can't tell if one SHA-1 is older or newer than another just by looking at them.
 //////////////////////////
 하지만, 이것은 별로 유용하지 않다.
-CVS나 SVN의 키워드 치환(Keyword Substitution)을 써봤으면 날짜(Datestamp)도 가능했다는 것을 알고 있을 것이다. SHA는 그냥 해시이고 식별할 수 있을 뿐이지 다른 것을 알려주진 않는다. SHA만으로는 예전 것보다 새것인지 오래된 것인지는 알 수 없다.
+CVS나 SVN의 키워드 치환(Keyword Substitution)을 써봤으면 날짜(Datestamp)도 가능했다는 것을 알고 있을 것이다. SHA-1는 그냥 해시이고 식별할 수 있을 뿐이지 다른 것을 알려주진 않는다. SHA-1만으로는 예전 것보다 새것인지 오래된 것인지는 알 수 없다.
 
 //////////////////////////
 It turns out that you can write your own filters for doing substitutions in files on commit/checkout.
@@ -413,7 +413,7 @@ You have to be careful, though, because the `.gitattributes` file is committed a
 When you design these filters, they should be able to fail gracefully and have the project still work properly.
 //////////////////////////
 이 기능은 매우 강력해서 입맛대로 프로젝트를 맞춤 설정할 수 있다.
-`.git attributes` 파일은 커밋하는 파일이기 때문에 필터 드라이버(여기서는 `dater`) 설정이 되지 않은 사람에게도 배포된다. 물론 `dater` 설정이 안 돼 있는 사람에게는 에러가 난다.
+`.gitattributes` 파일은 커밋하는 파일이기 때문에 필터 드라이버(여기서는 `dater`) 설정이 되지 않은 사람에게도 배포된다. 물론 `dater` 설정이 안 돼 있는 사람에게는 에러가 난다.
 필터를 만들 때 이런 예외 상황도 고려해서 항상 잘 동작하게 해야 한다.
 
 //////////////////////////
@@ -510,12 +510,15 @@ Attribute를 아래와 같이 설정하면 이 파일은 그냥 두고 Merge한
 database.xml merge=ours
 ----
 
-[source,console]
-----
+//////////////////////////
 And then define a dummy `ours` merge strategy with:
-----
+//////////////////////////
+이제 `ours`라는 이름의 Merge 전략에 대한 아무것도 하지 않는 Driver를 아래와 같이 정의한다.
 
+[source,console]
+----
 $ git config --global merge.ours.driver true
+----
 
 //////////////////////////
 If you merge in the other branch, instead of having merge conflicts with the `database.xml` file, you see something like this:

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

@@ -380,15 +380,15 @@ Git에 들어 있는 diff 도구 말고 다른 도구로 바꿀 수 있다.
 
 //////////////////////////
 If you want to try this out, P4Merge works on all major platforms, so you should be able to do so.
-I'll use path names in the examples that work on Mac and Linux systems; for Windows, you'll have to change `/usr/local/bin` to an executable path in your environment.
+We'll use path names in the examples that work on Mac and Linux systems; for Windows, you'll have to change `/usr/local/bin` to an executable path in your environment.
 //////////////////////////
 P4Merge는 중요 플랫폼을 모두 지원하기 때문에 웬만한 환경이면 사용할 수 있다.
 여기서는 Mac과 Linux 시스템에 설치하는 것을 보여준다. 윈도에서 사용하려면 `/usr/local/bin` 경로만 윈도 경로로 바꿔준다.
 
 //////////////////////////
 To begin, download P4Merge from http://www.perforce.com/downloads/Perforce/[].
 Next, you'll set up external wrapper scripts to run your commands.
-I'll use the Mac path for the executable; in other systems, it will be where your `p4merge` binary is installed.
+We'll use the Mac path for the executable; in other systems, it will be where your `p4merge` binary is installed.
 Set up a merge wrapper script named `extMerge` that calls your binary with all the arguments provided:
 //////////////////////////
 먼저 http://www.perforce.com/downloads/Perforce/[] 에서 P4Merge를 내려받는다.

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

@@ -34,7 +34,7 @@ If you want to use the bundled hook scripts, you'll have to rename them; their f
 //////////////////////////
 To enable a hook script, put a file in the `hooks` subdirectory of your Git directory that is named appropriately and is executable.
 From that point forward, it should be called.
-I'll cover most of the major hook filenames here.
+We'll cover most of the major hook filenames here.
 //////////////////////////
 실행할 수 있는 스크립트 파일을 저장소의 `hooks` 디렉토리에 넣으면 훅 스크립트가 켜진다.
 이 스크립트는 앞으로 계속 호출된다.
@@ -101,7 +101,7 @@ You may use it in conjunction with a commit template to programmatically insert
 //////////////////////////
 The `commit-msg` hook takes one parameter, which again is the path to a temporary file that contains the commit message written by the developer.
 If this script exits non-zero, Git aborts the commit process, so you can use it to validate your project state or commit message before allowing a commit to go through.
-In the last section of this chapter, I'll demonstrate using this hook to check that your commit message is conformant to a required pattern.
+In the last section of this chapter, We'll demonstrate using this hook to check that your commit message is conformant to a required pattern.
 //////////////////////////
 `commit-msg` 훅은 커밋 메시지가 들어 있는 임시 파일의 경로를 아규먼트로 받는다.
 그리고 이 스크립트가 0이 아닌 값을 반환하면 커밋되지 않는다. 이 훅에서 최종적으로 커밋이 완료되기 전에 프로젝트 상태나 커밋 메시지를 검증한다.

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

@@ -87,7 +87,7 @@ Push할 때마다 커밋 메시지에 해당 스트링이 포함돼 있는지 
 //////////////////////////
 You can get a list of the SHA-1 values of all the commits that are being pushed by taking the `$newrev` and `$oldrev` values and passing them to a Git plumbing command called `git rev-list`.
 This is basically the `git log` command, but by default it prints out only the SHA-1 values and no other information.
-So, to get a list of all the commit SHAs introduced between one commit SHA and another, you can run something like this:
+So, to get a list of all the commit SHA-1s introduced between one commit SHA-1 and another, you can run something like this:
 //////////////////////////
 `$newrev`, `$oldrev` 변수와 `git rev-list`라는 Plumbing 명령어를 이용해서 Push하는 모든 커밋의 SHA-1 값을 알 수 있다.
 `git log`와 근본적으로 같은 명령이고 옵션을 하나도 주지 않으면 다른 정보 없이 SHA-1 값만 보여준다.
@@ -635,7 +635,6 @@ This script uses a syntax that wasn't covered in the Revision Selection section
 [source,ruby]
 ----
 `git rev-list ^#{sha}^@ refs/remotes/#{remote_ref}`
-.
 ----
 
 //////////////////////////

book/10-git-internals/1-git-internals.asc

@@ -32,7 +32,7 @@ Git 초기에는 (1.5 이전 버전) 사용자 인터페이스가 훨씬 복잡
 최근 몇 년간 Git은 다른 VCS처럼 쉽고 간결하게 사용자 인터페이스를 다듬어 왔다. 하지만, 여전히 복잡하고 배우기 어렵다는 선입견이 있다.
 
 //////////////////////////
-The content-addressable filesystem layer is amazingly cool, so I'll cover that first in this chapter; then, you'll learn about the transport mechanisms and the repository maintenance tasks that you may eventually have to deal with.
+The content-addressable filesystem layer is amazingly cool, so we'll cover that first in this chapter; then, you'll learn about the transport mechanisms and the repository maintenance tasks that you may eventually have to deal with.
 //////////////////////////
 우선 Content-addressable 파일 시스템은 정말 대단한 것이므로 먼저 다룬다. 그리고 나서 데이터 전송 원리를 배우고 마지막에는 저장소를 관리하는 법까지 배운다.
 

book/10-git-internals/sections/environment.asc

@@ -146,7 +146,7 @@ You can override this in individual cases by starting the pathspec with `:(glob)
 
 
 //////////////////////////
-==== Commiting
+==== Committing
 //////////////////////////
 ==== 커밋관련 변수
 

book/10-git-internals/sections/maintenance.asc

@@ -82,11 +82,11 @@ cac0cab538b970a37ea1e769cbbde608743bc96d refs/tags/v1.0
 
 //////////////////////////
 If you update a reference, Git doesn't edit this file but instead writes a new file to `refs/heads`.
-To get the appropriate SHA for a given reference, Git checks for that reference in the `refs` directory and then checks the `packed-refs` file as a fallback.
+To get the appropriate SHA-1 for a given reference, Git checks for that reference in the `refs` directory and then checks the `packed-refs` file as a fallback.
 However, if you can't find a reference in the `refs` directory, it's probably in your `packed-refs` file.
 //////////////////////////
 이 상태에서 Refs를 수정하면 파일을 수정하는 게 아니라 `refs/heads` 폴더에 파일을 새로 만든다.
-Git은 Refs가 가리키는 SHA 값을 찾을 때 먼저 `refs` 디렉토리에서 찾고 없으면 `packed-refs` 파일에서 찾는다.
+Git은 Refs가 가리키는 SHA-1 값을 찾을 때 먼저 `refs` 디렉토리에서 찾고 없으면 `packed-refs` 파일에서 찾는다.
 그러니까 어떤 Refs가 있는데 `refs` 디렉토리에서 못 찾으면 `packed-refs`에 있을 것이다.
 
 //////////////////////////
@@ -145,12 +145,12 @@ fdf4fc3344e67ab068f836878b6c4951e3b15f3d first commit
 
 //////////////////////////
 You've effectively lost the top two commits – you have no branch from which those commits are reachable.
-You need to find the latest commit SHA and then add a branch that points to it.
-The trick is finding that latest commit SHA – it's not like you've memorized it, right?
+You need to find the latest commit SHA-1 and then add a branch that points to it.
+The trick is finding that latest commit SHA-1 – it's not like you've memorized it, right?
 //////////////////////////
 최근 커밋 두 개는 어떤 브랜치도 가리키지 않는다. 잃어 버렸다고 볼 수 있다.
 그 두 커밋을 브랜치에 다시 포함하려면 마지막 커밋을 다시 찾아야 한다.
-SHA 값을 외웠을 리도 없고 뭔가 찾아낼 방법이 필요하다.
+SHA-1 값을 외웠을 리도 없고 뭔가 찾아낼 방법이 필요하다.
 
 //////////////////////////
 Often, the quickest way is to use a tool called `git reflog`.
@@ -188,7 +188,7 @@ Reflog message: updating HEAD
 Author: Scott Chacon <schacon@gmail.com>
 Date:   Fri May 22 18:22:37 2009 -0700
 
-        third commit
+		third commit
 
 commit ab1afef80fac8e34258ff41fc1b867c702daa24b
 Reflog: HEAD@{1} (Scott Chacon <schacon@gmail.com>)
@@ -255,10 +255,10 @@ dangling blob 7108f7ecb345ee9d0084193f147cdad4d2998293
 
 //////////////////////////
 In this case, you can see your missing commit after the string ``dangling commit''.
-You can recover it the same way, by adding a branch that points to that SHA.
+You can recover it the same way, by adding a branch that points to that SHA-1.
 //////////////////////////
 이 Dangling 커밋이 잃어버린 커밋이니까
-그 SHA를 가리키는 브랜치를 만들어 복구할 수 있다.
+그 SHA-1를 가리키는 브랜치를 만들어 복구할 수 있다.
 
 [[_removing_objects]]
 //////////////////////////
@@ -399,12 +399,12 @@ dadf7258d699da2c8d89b09ef6670edb7d5f91b4 commit 229 159 12
 //////////////////////////
 The big object is at the bottom: 5MB.
 To find out what file it is, you'll use the `rev-list` command, which you used briefly in <<_enforcing_commit_message_format>>.
-If you pass `--objects` to `rev-list`, it lists all the commit SHAs and also the blob SHAs with the file paths associated with them.
+If you pass `--objects` to `rev-list`, it lists all the commit SHA-1s and also the blob SHA-1s with the file paths associated with them.
 You can use this to find your blob's name:
 //////////////////////////
 마지막에 있는 개체가 5MB로 가장 크다.
 이제 그 파일이 정확히 무슨 파일인지 알아내야 한다.
-<<_enforcing_commit_message_format>> 에서 소개했던 `rev-list` 명령에 `--objects` 옵션을 추가하면 커밋의 SHA 값과 Blob 개체의 파일이름, SHA 값을 보여준다.
+<<_enforcing_commit_message_format>> 에서 소개했던 `rev-list` 명령에 `--objects` 옵션을 추가하면 커밋의 SHA-1 값과 Blob 개체의 파일이름, SHA-1 값을 보여준다.
 그 결과에서 해당 Blob의 이름을 찾는다.
 
 [source,console]
@@ -437,7 +437,7 @@ To do so, you use `filter-branch`, which you used in <<_rewriting_history>>:
 [source,console]
 ----
 $ git filter-branch --index-filter \
-  'git rm --cached --ignore-unmatch git.tgz' -- 7b30847^..
+  'git rm --ignore-unmatch --cached git.tgz' -- 7b30847^..
 Rewrite 7b30847d080183a1ab7d18fb202473b3096e9f34 (1/2)rm 'git.tgz'
 Rewrite dadf7258d699da2c8d89b09ef6670edb7d5f91b4 (2/2)
 Ref 'refs/heads/master' was rewritten
@@ -453,14 +453,14 @@ Rather than remove a specific file with something like `rm file`, you have to re
 The reason to do it this way is speed – because Git doesn't have to check out each revision to disk before running your filter, the process can be much, much faster.
 You can accomplish the same task with `--tree-filter` if you want.
 The `--ignore-unmatch` option to `git rm` tells it not to error out if the pattern you're trying to remove isn't there.
-Finally, you ask `filter-branch` to rewrite your history only from the `6df7640` commit up, because you know that is where this problem started.
+Finally, you ask `filter-branch` to rewrite your history only from the `7b30847` commit up, because you know that is where this problem started.
 Otherwise, it will start from the beginning and will unnecessarily take longer.
 //////////////////////////
 삭제도 `rm file` 명령이 아니라 `git rm --cached` 명령으로 삭제한다. 디스크에서 삭제하는 것이 아니라 Index에서 삭제하는 것이다.
 이렇게 하는 이유는 속도가 빠르기 때문이다. Filter를 실행할 때마다 각 리비전을 디스크에 Checkout하지 않기 때문에 이것이 울트라 캡숑 더 빠르다.
 `--tree-filter`로도 같은 작업을 할 수 있다. 단지 느릴 뿐이다.
 그리고 `git rm` 명령에 `--ignore-unmatch` 옵션을 주면 파일이 없는 경우에 에러를 출력하지 않는다.
-마지막으로 문제가 생긴 것은 `6df7640` 커밋부터라서 `filter-branch` 명령에 `6df7640` 커밋부터 재작성하라고 알려줘야 한다.
+마지막으로 문제가 생긴 것은 `6df7640` 커밋부터라서 `filter-branch` 명령에 `7b30847` 커밋부터 재작성하라고 알려줘야 한다.
 그렇지 않으면 첫 커밋부터 시작해서 불필요한 것까지 재작성해 버린다.
 
 //////////////////////////

book/10-git-internals/sections/objects.asc

@@ -68,7 +68,7 @@ $ find .git/objects -type f
 //////////////////////////
 You can see a file in the `objects` directory.
 This is how Git stores the content initially – as a single file per piece of content, named with the SHA-1 checksum of the content and its header.
-The subdirectory is named with the first 2 characters of the SHA, and the filename is the remaining 38 characters.
+The subdirectory is named with the first 2 characters of the SHA-1, and the filename is the remaining 38 characters.
 //////////////////////////
 `objects` 디렉토리에 파일이 하나 새로 생겼다.
 데이터는 새로 만든 파일에 저장하며 Git은 데이터를 저장할 때 데이터와 헤더로 생성한 SHA-1 체크섬으로 파일 이름을 짓는다.
@@ -182,7 +182,7 @@ The next type we'll look at is the tree, which solves the problem of storing the
 Git stores content in a manner similar to a UNIX filesystem, but a bit simplified.
 All the content is stored as tree and blob objects, with trees corresponding to UNIX directory entries and blobs corresponding more or less to inodes or file contents.
 A single tree object contains one or more tree entries, each of which contains a SHA-1 pointer to a blob or subtree with its associated mode, type, and filename.
-For example, the most recent tree in the a project may look something like this:
+For example, the most recent tree in a project may look something like this:
 //////////////////////////
 다음은 Tree 개체를 살펴보자. 이 Tree 개체에 파일 이름을 저장한다. 파일 여러 개를 한꺼번에 저장할 수도 있다.
 Git은 유닉스 파일 시스템과 비슷한 방법으로 저장하지만 좀 더 단순하다.
@@ -310,7 +310,7 @@ $ git cat-file -p 0155eb4229851634a0f03eb265b69f5a2d56f341
 ----
 
 //////////////////////////
-Notice that this tree has both file entries and also that the test.txt SHA is the ``version 2'' SHA from earlier (`1f7a7a`).
+Notice that this tree has both file entries and also that the test.txt SHA-1 is the ``version 2'' SHA from earlier (`1f7a7a`).
 Just for fun, you'll add the first tree as a subdirectory into this one.
 You can read trees into your staging area by calling `read-tree`.
 In this case, you can read an existing tree into your staging area as a subtree by using the `--prefix` option to `read-tree`:
@@ -420,7 +420,7 @@ commit 1a410efbd13591db07496601ebc7a059dd55cfe9
 Author: Scott Chacon <schacon@gmail.com>
 Date:   Fri May 22 18:15:24 2009 -0700
 
-    third commit
+	third commit
 
  bak/test.txt | 1 +
  1 file changed, 1 insertion(+)
@@ -429,7 +429,7 @@ commit cac0cab538b970a37ea1e769cbbde608743bc96d
 Author: Scott Chacon <schacon@gmail.com>
 Date:   Fri May 22 18:14:29 2009 -0700
 
-    second commit
+	second commit
 
  new.txt  | 1 +
  test.txt | 2 +-