Update 20160403

.tgitconfig

@@ -0,0 +1,6 @@
+[bugtraq]
+	url = https://github.com/progit/progit2/issues/%BUGID%
+	logregex = "[Ii]ssues?:?(\\s*(,|and)?\\s*#?\\d+)+\n(\\d+)"
+
+[tgit]
+	icon = Pro.ico

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

@@ -41,7 +41,7 @@ Each level overrides values in the previous level, so values in `.git/config` tr
 //////////////////////////
 On Windows systems, Git looks for the `.gitconfig` file in the `$HOME` directory (`C:\Users\$USER` for most people).
 It also still looks for `/etc/gitconfig`, although it's relative to the MSys root, which is wherever you decide to install Git on your Windows system when you run the installer.
-If you are using Git for Windows 2.x or later, there is also a system-level config file at
+If you are using version 2.x or later of Git for Windows, there is also a system-level config file at
 `C:\Documents and Settings\All Users\Application Data\Git\config` on Windows XP, and in `C:\ProgramData\Git\config` on Windows Vista and newer.
 This config file can only be changed by `git config -f <file>` as an admin.
 //////////////////////////

book/01-introduction/sections/installing.asc

@@ -139,18 +139,18 @@ The binary installers tend to be a bit behind, though as Git has matured in rece
 インストーラーは最新からは少しですが遅れがちです。とはいえ、Gitの完成度が高まってきたおかげで、今ではその差はさほどでもありません。
 
 //////////////////////////
-If you do want to install Git from source, you need to have the following libraries that Git depends on: curl, zlib, openssl, expat, and libiconv.
+If you do want to install Git from source, you need to have the following libraries that Git depends on: autotools, curl, zlib, openssl, expat, and libiconv.
 For example, if you're on a system that has yum (such as Fedora) or apt-get (such as a Debian based system), you can use one of these commands to install the minimal dependencies for compiling and installing the Git binaries:
 //////////////////////////
-Gitをソースからインストールするのなら、Gitが依存する以下のライブラリが必要です：curl、zlib、openssl、expat、libiconv
+Gitをソースからインストールするのなら、Gitが依存する以下のライブラリが必要です：autotools、curl、zlib、openssl、expat、libiconv
 もし、使っているシステムでyumが使えたり（Fedoraなど）、apt-getが使えたり（Debianベースのシステムなど）する場合は、それぞれ次のようなコマンドを使うと Git のバイナリをコンパイルしインストールするための必要最低限の依存ライブラリをインストールしてくれます。
 
 [source,console]
 ----
-$ sudo yum install curl-devel expat-devel gettext-devel \
+$ sudo yum install dh-autoreconf curl-devel expat-devel gettext-devel \
   openssl-devel perl-devel zlib-devel
-$ sudo apt-get install libcurl4-gnutls-dev libexpat1-dev gettext \
-  libz-dev libssl-dev
+$ sudo apt-get install dh-autoreconf libcurl4-gnutls-dev libexpat1-dev \
+  gettext libz-dev libssl-dev
 ----
 
 //////////////////////////

book/02-git-basics/sections/recording-changes.asc

@@ -14,7 +14,7 @@ You need to make some changes and commit snapshots of those changes into your re
 Remember that each file in your working directory can be in one of two states: tracked or untracked.
 Tracked files are files that were in the last snapshot; they can be unmodified, modified, or staged.
 Untracked files are everything else – any files in your working directory that were not in your last snapshot and are not in your staging area.
-When you first clone a repository, all of your files will be tracked and unmodified because you just checked them out and haven't edited anything.
+When you first clone a repository, all of your files will be tracked and unmodified because Git just checked them out and you haven't edited anything.
 //////////////////////////
 作業コピー内の各ファイルには追跡されている(tracked)ものと追跡されてない(untracked)ものの二通りがあることを知っておきましょう。
 追跡されているファイルとは、直近のスナップショットに存在したファイルのことです。これらのファイルについては変更されていない(unmodified)」「変更されている(modified)」「ステージされている(staged)」の三つの状態があります。
@@ -52,6 +52,7 @@ If you run this command directly after a clone, you should see something like th
 ----
 $ git status
 On branch master
+Your branch is up-to-date with 'origin/master'.
 nothing to commit, working directory clean
 ----
 
@@ -60,7 +61,7 @@ This means you have a clean working directory – in other words, there are no t
 Git also doesn't see any untracked files, or they would be listed here.
 Finally, the command tells you which branch you're on and informs you that it has not diverged from the same branch on the server.
 For now, that branch is always ``master'', which is the default; you won't worry about it here.
-<<ch03-git-branching#ch03-git-branching>>  will go over branches and references in detail.
+<<ch03-git-branching#ch03-git-branching>> will go over branches and references in detail.
 //////////////////////////
 これは、クリーンな作業コピーである (つまり、追跡されているファイルの中に変更されているものがない) ことを意味します。
 また、追跡されていないファイルも存在しません (もし追跡されていないファイルがあれば、Git はそれを表示します)。
@@ -80,6 +81,7 @@ If the file didn't exist before, and you run `git status`, you see your untracke
 $ echo 'My Project' > README
 $ git status
 On branch master
+Your branch is up-to-date with 'origin/master'.
 Untracked files:
   (use "git add <file>..." to include in what will be committed)
 
@@ -126,6 +128,7 @@ If you run your status command again, you can see that your README file is now t
 ----
 $ git status
 On branch master
+Your branch is up-to-date with 'origin/master'.
 Changes to be committed:
   (use "git reset HEAD <file>..." to unstage)
 
@@ -160,6 +163,7 @@ If you change a previously tracked file called `CONTRIBUTING.md` and then run yo
 ----
 $ git status
 On branch master
+Your branch is up-to-date with 'origin/master'.
 Changes to be committed:
   (use "git reset HEAD <file>..." to unstage)
 
@@ -189,6 +193,7 @@ Let's run `git add` now to stage the `CONTRIBUTING.md` file, and then run `git s
 $ git add CONTRIBUTING.md
 $ git status
 On branch master
+Your branch is up-to-date with 'origin/master'.
 Changes to be committed:
   (use "git reset HEAD <file>..." to unstage)
 
@@ -213,6 +218,7 @@ However, let's run `git status` one more time:
 $ vim CONTRIBUTING.md
 $ git status
 On branch master
+Your branch is up-to-date with 'origin/master'.
 Changes to be committed:
   (use "git reset HEAD <file>..." to unstage)
 
@@ -247,6 +253,7 @@ If you modify a file after you run `git add`, you have to run `git add` again to
 $ git add CONTRIBUTING.md
 $ git status
 On branch master
+Your branch is up-to-date with 'origin/master'.
 Changes to be committed:
   (use "git reset HEAD <file>..." to unstage)
 
@@ -280,7 +287,7 @@ M  lib/simplegit.rb
 
 //////////////////////////
 New files that aren't tracked have a `??` next to them, new files that have been added to the staging area have an `A`, modified files have an `M` and so on.
-There are two columns to the output - the left hand column indicates that the file is staged and the right hand column indicates that it's modified.
+There are two columns to the output - the left-hand column indicates the status of the staging area and the right-hand column indicates the status of the working tree.
 So for example in that output, the `README` file is modified in the working directory but not yet staged, while the `lib/simplegit.rb` file is modified and staged.
 The `Rakefile` was modified, staged and then modified again, so there are changes to it that are both staged and unstaged.
 //////////////////////////
@@ -316,7 +323,7 @@ $ cat .gitignore
 
 //////////////////////////
 The first line tells Git to ignore any files ending in ``.o'' or ``.a'' – object and archive files that may be the product of building your code.
-The second line tells Git to ignore all files that end with a tilde (`~`), which is used by many text editors such as Emacs to mark temporary files.
+The second line tells Git to ignore all files whose names end with a tilde (`~`), which is used by many text editors such as Emacs to mark temporary files.
 You may also include a log, tmp, or pid directory; automatically generated documentation; and so on.
 Setting up a `.gitignore` file before you get going is generally a good idea so you don't accidentally commit files that you really don't want in your Git repository.
 //////////////////////////
@@ -425,6 +432,7 @@ If you run your `git status` command, you once again see something like this:
 ----
 $ git status
 On branch master
+Your branch is up-to-date with 'origin/master'.
 Changes to be committed:
   (use "git reset HEAD <file>..." to unstage)
 
@@ -509,6 +517,7 @@ $ git add CONTRIBUTING.md
 $ echo '# test line' >> CONTRIBUTING.md
 $ git status
 On branch master
+Your branch is up-to-date with 'origin/master'.
 Changes to be committed:
   (use "git reset HEAD <file>..." to unstage)
 
@@ -631,6 +640,8 @@ The editor displays the following text (this example is a Vim screen):
 # Please enter the commit message for your changes. Lines starting
 # with '#' will be ignored, and an empty message aborts the commit.
 # On branch master
+# Your branch is up-to-date with 'origin/master'.
+#
 # Changes to be committed:
 #	new file:   README
 #	modified:   CONTRIBUTING.md
@@ -712,6 +723,7 @@ Adding the `-a` option to the `git commit` command makes Git automatically stage
 ----
 $ git status
 On branch master
+Your branch is up-to-date with 'origin/master'.
 Changes not staged for commit:
   (use "git add <file>..." to update what will be committed)
   (use "git checkout -- <file>..." to discard changes in working directory)
@@ -779,6 +791,7 @@ $ git rm PROJECTS.md
 rm 'PROJECTS.md'
 $ git status
 On branch master
+Your branch is up-to-date with 'origin/master'.
 Changes to be committed:
   (use "git reset HEAD <file>..." to unstage)
 
@@ -840,7 +853,7 @@ $ git rm \*~
 ----
 
 //////////////////////////
-This command removes all files that end with `~`.
+This command removes all files whose names end with a `~`.
 //////////////////////////
 このコマンドは、`~` で終わるファイル名のファイルをすべて削除します。
 
@@ -883,6 +896,7 @@ In fact, if you run something like this and look at the status, you'll see that
 $ git mv README.md README
 $ git status
 On branch master
+Your branch is up-to-date with 'origin/master'.
 Changes to be committed:
   (use "git reset HEAD <file>..." to unstage)
 
@@ -903,9 +917,9 @@ $ git add README
 
 //////////////////////////
 Git figures out that it's a rename implicitly, so it doesn't matter if you rename a file that way or with the `mv` command.
-The only real difference is that `mv` is one command instead of three – it's a convenience function.
+The only real difference is that `git mv` is one command instead of three – it's a convenience function.
 More importantly, you can use any tool you like to rename a file, and address the add/rm later, before you commit.
 //////////////////////////
 Git はこれが暗黙的なファイル名の変更であると理解するので、この方法であろうが `mv` コマンドを使おうがどちらでもかまいません。
-唯一の違いは、この方法だと 3 つのコマンドが必要になるかわりに `mv` だとひとつのコマンドだけで実行できるという点です。
+唯一の違いは、この方法だと 3 つのコマンドが必要になるかわりに `git mv` だとひとつのコマンドだけで実行できるという点です。
 より重要なのは、ファイル名の変更は何でもお好みのツールで行えるということです。あとでコミットする前に add/rm を指示してやればいいのです。

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

@@ -101,10 +101,11 @@ Notice that these remotes use a variety of protocols; we'll cover more about thi
 ==== リモートリポジトリの追加
 
 //////////////////////////
-We've mentioned and given some demonstrations of adding remote repositories in previous sections, but here is how to do it explicitly.(((git commands, remote)))
+We've mentioned and given some demonstrations of how the 'clone' command implicitly adds the `origin` remote for you.
+Here's how to add a new remote explicitly.(((git commands, remote)))
 To add a new remote Git repository as a shortname you can reference easily, run `git remote add <shortname> <url>`:
 //////////////////////////
-これまでのセクションでも何度かリモートリポジトリの追加を行ってきましたが、
+これまでに何度かcloneコマンドがどのように `origin` のリモートリポジトリを暗黙的に追加するかを説明してきました。
 ここで改めてその方法をきちんと説明しておきます。(((git commands, remote)))
 新しいリモート Git リポジトリにアクセスしやすいような名前をつけて追加するには、
 `git remote add <shortname> <url>` を実行します。
@@ -174,7 +175,7 @@ After you do this, you should have references to all the branches from that remo
 //////////////////////////
 If you clone a repository, the command automatically adds that remote repository under the name ``origin''.
 So, `git fetch origin` fetches any new work that has been pushed to that server since you cloned (or last fetched from) it.
-It's important to note that the `git fetch` command pulls the data to your local repository – it doesn't automatically merge it with any of your work or modify what you're currently working on.
+It's important to note that the `git fetch` command only downloads the data to your local repository – it doesn't automatically merge it with any of your work or modify what you're currently working on.
 You have to merge it manually into your work when you're ready.
 //////////////////////////
 リポジトリをクローンしたときには、リモートリポジトリに対して自動的に ``origin'' という名前がつけられます。
@@ -184,11 +185,11 @@ You have to merge it manually into your work when you're ready.
 したがって、必要に応じて自分でマージをする必要があります。
 
 //////////////////////////
-If you have a branch set up to track a remote branch (see the next section and <<ch03-git-branching#ch03-git-branching>> for more information), you can use the `git pull` command to automatically fetch and then merge a remote branch into your current branch.(((git commands, pull)))
+If your current branch is set up to track a remote branch (see the next section and <<ch03-git-branching#ch03-git-branching>> for more information), you can use the `git pull` command to automatically fetch and then merge that remote branch into your current branch.(((git commands, pull)))
 This may be an easier or more comfortable workflow for you; and by default, the `git clone` command automatically sets up your local master branch to track the remote master branch (or whatever the default branch is called) on the server you cloned from.
 Running `git pull` generally fetches data from the server you originally cloned from and automatically tries to merge it into the code you're currently working on.
 //////////////////////////
-リモートブランチを追跡するためのブランチを作成すれば (次のセクションと <<ch03-git-branching#ch03-git-branching>> で詳しく説明します)、`git pull` コマンドを使うことができます。
+現在のブランチがリモートブランチを追跡するように設定されている場合 (次のセクションと <<ch03-git-branching#ch03-git-branching>> で詳しく説明します)、`git pull` コマンドを使うことができます。
 これは、自動的にフェッチを行い、リモートブランチの内容を現在のブランチにマージします。(((git commands, pull)))
 おそらくこのほうが、よりお手軽で使いやすいことでしょう。
 また、 `git clone` コマンドはローカルの master ブランチ（実際のところ、デフォルトブランチであれば名前はなんでもかまいません）がリモートの master ブランチを追跡するよう、デフォルトで自動設定します。
@@ -217,7 +218,7 @@ $ git push origin master
 //////////////////////////
 This command works only if you cloned from a server to which you have write access and if nobody has pushed in the meantime.
 If you and someone else clone at the same time and they push upstream and then you push upstream, your push will rightly be rejected.
-You'll have to pull down their work first and incorporate it into yours before you'll be allowed to push.
+You'll have to fetch their work first and incorporate it into yours before you'll be allowed to push.
 See <<ch03-git-branching#ch03-git-branching>> for more detailed information on how to push to remote servers.
 //////////////////////////
 このコマンドが動作するのは、自分が書き込みアクセス権を持つサーバーからクローンし、かつその後だれもそのサーバーにプッシュしていない場合のみです。
@@ -295,18 +296,18 @@ $ git remote show origin
 
 //////////////////////////
 This command shows which branch is automatically pushed to when you run `git push` while on certain branches.
-It also shows you which remote branches on the server you don't yet have, which remote branches you have that have been removed from the server, and multiple branches that are automatically merged when you run `git pull`.
+It also shows you which remote branches on the server you don't yet have, which remote branches you have that have been removed from the server, and multiple local branches that are able to merge automatically with their remote-tracking branch when you run `git pull`.
 //////////////////////////
 このコマンドは、特定のブランチ上で `git push` したときにどのブランチに自動プッシュされるのかを表示しています。
-また、サーバー上のリモートブランチのうちまだ手元に持っていないもの、手元にあるブランチのうちすでにサーバー上では削除されているもの、`git pull` を実行したときに自動的にマージされるブランチなども表示されています。
+また、サーバー上のリモートブランチのうちまだ手元に持っていないもの、手元にあるブランチのうちすでにサーバー上では削除されているもの、`git pull` を実行したときにリモート追跡ブランチと自動的にマージできるローカルのブランチなども表示されています。
 
 //////////////////////////
 ==== Removing and Renaming Remotes
 //////////////////////////
 ==== リモートの削除・リネーム
 
 //////////////////////////
-If you want to rename a reference you can run `git remote rename` to change a remote's shortname.(((git commands, remote)))
+You can run `git remote rename` to change a remote's shortname.(((git commands, remote)))
 For instance, if you want to rename `pb` to `paul`, you can do so with `git remote rename`:
 //////////////////////////
 リモートを参照する名前を変更したい場合、 `git remote rename` を使うことができます。(((git commands, remote)))
@@ -321,10 +322,10 @@ paul
 ----
 
 //////////////////////////
-It's worth mentioning that this changes your remote branch names, too.
+It's worth mentioning that this changes all your remote-tracking branch names, too.
 What used to be referenced at `pb/master` is now at `paul/master`.
 //////////////////////////
-そうすると、リモートブランチ名も併せて変更されることを付け加えておきましょう。
+そうすると、全てのリモート追跡ブランチ名も併せて変更されることを付け加えておきましょう。
 これまで `pb/master` として参照していたブランチは、これからは `paul/master` となります。
 
 //////////////////////////