diff --git a/.tgitconfig b/.tgitconfig new file mode 100644 index 00000000..9a9773b3 --- /dev/null +++ b/.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 diff --git a/Pro.ico b/Pro.ico new file mode 100644 index 00000000..992dcc6d Binary files /dev/null and b/Pro.ico differ diff --git a/book/01-introduction/sections/first-time-setup.asc b/book/01-introduction/sections/first-time-setup.asc index 12ccf95f..a9adec64 100644 --- a/book/01-introduction/sections/first-time-setup.asc +++ b/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 ` as an admin. ////////////////////////// diff --git a/book/01-introduction/sections/installing.asc b/book/01-introduction/sections/installing.asc index 7ab12ebf..b24c20bf 100644 --- a/book/01-introduction/sections/installing.asc +++ b/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 ---- ////////////////////////// diff --git a/book/02-git-basics/sections/recording-changes.asc b/book/02-git-basics/sections/recording-changes.asc index 2f75c7d4..1f2d3762 100644 --- a/book/02-git-basics/sections/recording-changes.asc +++ b/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. -<> will go over branches and references in detail. +<> 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 ..." 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 ..." 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 ..." 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 ..." 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 ..." 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 ..." 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 ..." 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 ..." 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 ..." to update what will be committed) (use "git checkout -- ..." 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 ..." 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 ..." 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 を指示してやればいいのです。 diff --git a/book/02-git-basics/sections/remotes.asc b/book/02-git-basics/sections/remotes.asc index f7830a39..9be83c73 100644 --- a/book/02-git-basics/sections/remotes.asc +++ b/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 `: ////////////////////////// -これまでのセクションでも何度かリモートリポジトリの追加を行ってきましたが、 +これまでに何度かcloneコマンドがどのように `origin` のリモートリポジトリを暗黙的に追加するかを説明してきました。 ここで改めてその方法をきちんと説明しておきます。(((git commands, remote))) 新しいリモート Git リポジトリにアクセスしやすいような名前をつけて追加するには、 `git remote add ` を実行します。 @@ -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 <> 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 <> 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. ////////////////////////// -リモートブランチを追跡するためのブランチを作成すれば (次のセクションと <> で詳しく説明します)、`git pull` コマンドを使うことができます。 +現在のブランチがリモートブランチを追跡するように設定されている場合 (次のセクションと <> で詳しく説明します)、`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 <> for more detailed information on how to push to remote servers. ////////////////////////// このコマンドが動作するのは、自分が書き込みアクセス権を持つサーバーからクローンし、かつその後だれもそのサーバーにプッシュしていない場合のみです。 @@ -295,10 +296,10 @@ $ 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 @@ -306,7 +307,7 @@ It also shows you which remote branches on the server you don't yet have, which ==== リモートの削除・リネーム ////////////////////////// -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` となります。 ////////////////////////// diff --git a/book/02-git-basics/sections/undoing.asc b/book/02-git-basics/sections/undoing.asc index 89e87eb0..c2893971 100644 --- a/book/02-git-basics/sections/undoing.asc +++ b/book/02-git-basics/sections/undoing.asc @@ -196,7 +196,7 @@ You can see that the changes have been reverted. ////////////////////////// ===== It's important to understand that `git checkout -- ` is a dangerous command. -Any changes you made to that file are gone – you just copied another file over it. +Any changes you made to that file are gone – Git just copied another file over it. Don't ever use this command unless you absolutely know that you don't want the file. ===== ////////////////////////// diff --git a/book/02-git-basics/sections/viewing-history.asc b/book/02-git-basics/sections/viewing-history.asc index c828a5cf..59f137d3 100644 --- a/book/02-git-basics/sections/viewing-history.asc +++ b/book/02-git-basics/sections/viewing-history.asc @@ -206,9 +206,9 @@ a11bef0 - Scott Chacon, 6 years ago : first commit ---- ////////////////////////// -<> lists some of the more useful options that format takes. +<> lists some of the more useful options that `format` takes. ////////////////////////// -<> は、format で使用できる便利なオプションをまとめたものです。 +<> は、`format` で使用できる便利なオプションをまとめたものです。 [[rpretty_format]] ////////////////////////// diff --git a/book/03-git-branching/sections/basic-branching-and-merging.asc b/book/03-git-branching/sections/basic-branching-and-merging.asc index b4e94c17..35e901db 100644 --- a/book/03-git-branching/sections/basic-branching-and-merging.asc +++ b/book/03-git-branching/sections/basic-branching-and-merging.asc @@ -189,11 +189,11 @@ Fast-forward ////////////////////////// You'll notice the phrase ``fast-forward'' in that merge. -Because the commit pointed to by the branch you merged in was directly upstream of the commit you're on, Git simply moves the pointer forward. +Because the commit `C4` pointed to by the branch `hotfix` you merged in was directly ahead of the commit `C2` you're on, Git simply moves the pointer forward. To phrase that another way, when you try to merge one commit with a commit that can be reached by following the first commit's history, Git simplifies things by moving the pointer forward because there is no divergent work to merge together – this is called a ``fast-forward.'' ////////////////////////// このマージ処理で ``fast-forward'' というフレーズが登場したのにお気づきでしょうか。 -マージ先のブランチが指すコミットがマージ元のコミットの直接の親であるため、Git がポインタを前に進めたのです。 +マージしたブランチ `hotfix` が指すコミット `C4` がマージ元のコミット `C2` の直接の親であるため、Git がポインタを前に進めたのです。 言い換えると、あるコミットに対してコミット履歴上で直接到達できる別のコミットをマージしようとした場合、Git は単にポインタを前に進めるだけで済ませます。 マージ対象が分岐しているわけではないからです。 この処理のことを ``fast-forward'' と言います。 diff --git a/book/04-git-server/sections/git-daemon.asc b/book/04-git-server/sections/git-daemon.asc index 08301fc0..df38b2d9 100644 --- a/book/04-git-server/sections/git-daemon.asc +++ b/book/04-git-server/sections/git-daemon.asc @@ -63,7 +63,6 @@ stop on shutdown exec /usr/bin/git daemon \ --user=git --group=git \ --reuseaddr \ - --detach \ --base-path=/opt/git/ \ /opt/git/ respawn diff --git a/book/04-git-server/sections/git-on-a-server.asc b/book/04-git-server/sections/git-on-a-server.asc index 7374d24c..cccffc5a 100644 --- a/book/04-git-server/sections/git-on-a-server.asc +++ b/book/04-git-server/sections/git-on-a-server.asc @@ -69,32 +69,32 @@ It takes the Git repository by itself, without a working directory, and creates ////////////////////////// Now that you have a bare copy of your repository, all you need to do is put it on a server and set up your protocols. -Let's say you've set up a server called `git.example.com` that you have SSH access to, and you want to store all your Git repositories under the `/opt/git` directory. -Assuming that `/opt/git` exists on that server, you can set up your new repository by copying your bare repository over: +Let's say you've set up a server called `git.example.com` that you have SSH access to, and you want to store all your Git repositories under the `/srv/git` directory. +Assuming that `/srv/git` exists on that server, you can set up your new repository by copying your bare repository over: ////////////////////////// ベアリポジトリを取得できたので、あとはそれをサーバー上においてプロトコルを準備するだけです。 -ここでは、`git.example.com` というサーバーがあってそこに SSH でアクセスできるものと仮定しましょう。Git リポジトリはサーバー上の `/opt/git` ディレクトリに置く予定です。 -`/opt/git` ディレクトリが作成済みであれば、新しいリポジトリを作成するには、ベアリポジトリを次のようにコピーします。 +ここでは、`git.example.com` というサーバーがあってそこに SSH でアクセスできるものと仮定しましょう。Git リポジトリはサーバー上の `/srv/git` ディレクトリに置く予定です。 +`/srv/git` ディレクトリが作成済みであれば、新しいリポジトリを作成するには、ベアリポジトリを次のようにコピーします。 [source,console] ---- -$ scp -r my_project.git user@git.example.com:/opt/git +$ scp -r my_project.git user@git.example.com:/srv/git ---- ////////////////////////// -At this point, other users who have SSH access to the same server which has read-access to the `/opt/git` directory can clone your repository by running +At this point, other users who have SSH access to the same server which has read-access to the `/srv/git` directory can clone your repository by running ////////////////////////// -この時点で、同じサーバーに SSH でアクセスできてかつ `/opt/git` ディレクトリへの読み込みアクセス権限がある人なら、次のようにしてこのリポジトリをクローンできるようになりました。 +この時点で、同じサーバーに SSH でアクセスできてかつ `/srv/git` ディレクトリへの読み込みアクセス権限がある人なら、次のようにしてこのリポジトリをクローンできるようになりました。 [source,console] ---- -$ git clone user@git.example.com:/opt/git/my_project.git +$ git clone user@git.example.com:/srv/git/my_project.git ---- ////////////////////////// -If a user SSHs into a server and has write access to the `/opt/git/my_project.git` directory, they will also automatically have push access. +If a user SSHs into a server and has write access to the `/srv/git/my_project.git` directory, they will also automatically have push access. ////////////////////////// -ユーザーが SSH でアクセスでき、かつ `/opt/git/my_project.git` ディレクトリへの書き込みアクセス権限があれば、すでにプッシュもできる状態になっています。 +ユーザーが SSH でアクセスでき、かつ `/srv/git/my_project.git` ディレクトリへの書き込みアクセス権限があれば、すでにプッシュもできる状態になっています。 ////////////////////////// Git will automatically add group write permissions to a repository properly if you run the `git init` command with the `--shared` option.(((git commands, init, bare))) @@ -104,7 +104,7 @@ Git will automatically add group write permissions to a repository properly if y [source,console] ---- $ ssh user@git.example.com -$ cd /opt/git/my_project.git +$ cd /srv/git/my_project.git $ git init --bare --shared ---- diff --git a/book/05-distributed-git/sections/contributing.asc b/book/05-distributed-git/sections/contributing.asc index 7d099665..df112230 100644 --- a/book/05-distributed-git/sections/contributing.asc +++ b/book/05-distributed-git/sections/contributing.asc @@ -571,7 +571,7 @@ image::images/small-team-7.png[すべての変更をサーバーに書き戻し ////////////////////////// That is one of the simplest workflows. You work for a while, generally in a topic branch, and merge into your master branch when it's ready to be integrated. -When you want to share that work, you merge it into your own master branch, then fetch and merge `origin/master` if it has changed, and finally push to the `master` branch on the server. +When you want to share that work, you fetch and merge your master from `origin/master` if it has changed, and finally push to the `master` branch on the server. The general sequence is something like this: ////////////////////////// これがもっとも単純なワークフローです。 diff --git a/book/07-git-tools/git-credential-read-only b/book/07-git-tools/git-credential-read-only index ec8f4d1f..b98833c4 100755 --- a/book/07-git-tools/git-credential-read-only +++ b/book/07-git-tools/git-credential-read-only @@ -22,7 +22,7 @@ end File.readlines(path).each do |fileline| # <4> prot,user,pass,host = fileline.scan(/^(.*?):\/\/(.*?):(.*?)@(.*)$/).first - if prot == known['protocol'] and host == known['host'] then + if prot == known['protocol'] and host == known['host'] and user == known['username'] then puts "protocol=#{prot}" puts "host=#{host}" puts "username=#{user}" diff --git a/book/07-git-tools/sections/credentials.asc b/book/07-git-tools/sections/credentials.asc index 723b2e90..c557da6d 100644 --- a/book/07-git-tools/sections/credentials.asc +++ b/book/07-git-tools/sections/credentials.asc @@ -71,7 +71,7 @@ Here's an example of how you'd configure the ``store'' helper with a custom file [source,console] ---- -$ git config --global credential.helper store --file ~/.my-credentials +$ git config --global credential.helper 'store --file ~/.my-credentials' ---- ////////////////////////// @@ -339,7 +339,7 @@ Since its name starts with ``git-'', we can use the simple syntax for the config [source,console] ---- -$ git config --global credential.helper read-only --file /mnt/shared/creds +$ git config --global credential.helper 'read-only --file /mnt/shared/creds' ---- ////////////////////////// diff --git a/book/08-customizing-git/sections/config.asc b/book/08-customizing-git/sections/config.asc index 06551fcf..58b31392 100644 --- a/book/08-customizing-git/sections/config.asc +++ b/book/08-customizing-git/sections/config.asc @@ -226,11 +226,11 @@ You can put patterns in your project's `.gitignore` file to have Git not see the ////////////////////////// But sometimes you want to ignore certain files for all repositories that you work with. If your computer is running Mac OS X, you're probably familiar with `.DS_Store` files. -If your preferred editor is Emacs or Vim, you know about files that end with a `~`. +If your preferred editor is Emacs or Vim, you know about filenames that end with a `~` or `.swp`. ////////////////////////// ですが、作業中のすべてのリポジトリで、ある特定のファイルを無視したい場合もあります。 Mac OS X を使っているのなら、 `.DS_Store` というファイルに見おぼえがあるでしょう。 -使っているエディタが Emacs か Vim なら、 `~` で終わるファイルのことを知っていることと思います。 +使っているエディタが Emacs か Vim なら、 `~` で終わるファイル名のことを知っていることと思います。 ////////////////////////// This setting lets you write a kind of global `.gitignore` file. @@ -242,6 +242,7 @@ If you create a `~/.gitignore_global` file with these contents: [source,ini] ---- *~ +.*.swp .DS_Store ---- diff --git a/book/09-git-and-other-scms/sections/import-svn.asc b/book/09-git-and-other-scms/sections/import-svn.asc index 2db8b809..172d8152 100644 --- a/book/09-git-and-other-scms/sections/import-svn.asc +++ b/book/09-git-and-other-scms/sections/import-svn.asc @@ -46,10 +46,12 @@ Then, redirect that output into your `users.txt` file so you can add the equival ////////////////////////// You can provide this file to `git svn` to help it map the author data more accurately. -You can also tell `git svn` not to include the metadata that Subversion normally imports, by passing `--no-metadata` to the `clone` or `init` command. +You can also tell `git svn` not to include the metadata that Subversion normally imports, by passing `--no-metadata` to the `clone` or `init` command (though if you want to keep the synchronisation-metadata, feel free to omit this parameter). This makes your `import` command look like this: ////////////////////////// -このファイルを `git svn` に渡せば、作者のデータをより正確にマッピングできるようになります。また、Subversion が通常インポートするメタデータを含めないよう `git svn` に指示することもできます。そのためには `--no-metadata` を `clone` コマンドあるいは `init` コマンドに渡します。そうすると、 `import` コマンドは次のようになります。 +このファイルを `git svn` に渡せば、作者のデータをより正確にマッピングできるようになります。 +また、Subversion が通常インポートするメタデータを含めないよう `git svn` に指示することもできます。そのためには `--no-metadata` を `clone` コマンドあるいは `init` コマンドに渡します（同期メタデータを維持したい場合はこのパラメータを省略してください）。 +そうすると、 `import` コマンドは次のようになります。 [source,console] ---- diff --git a/book/09-git-and-other-scms/sections/import-tfs.asc b/book/09-git-and-other-scms/sections/import-tfs.asc index 74292e48..fdc92780 100644 --- a/book/09-git-and-other-scms/sections/import-tfs.asc +++ b/book/09-git-and-other-scms/sections/import-tfs.asc @@ -42,18 +42,18 @@ AUTHORS_TMP ファイルを開いて、2番目のカラムの開始位置と終 [source,powershell] ---- -PS> cat AUTHORS_TMP | cut -b 11-20 | tail -n+3 | uniq | sort > AUTHORS +PS> cat AUTHORS_TMP | cut -b 11-20 | tail -n+3 | sort | uniq > AUTHORS ---- ////////////////////////// The `cut` command keeps only the characters between 11 and 20 from each line. The `tail` command skips the first two lines, which are field headers and ASCII-art underlines. -The result of all of this is piped to `uniq` to eliminate duplicates, and saved to a file named `AUTHORS`. +The result of all of this is piped to `sort` and `uniq` to eliminate duplicates, and saved to a file named `AUTHORS`. The next step is manual; in order for git-tfs to make effective use of this file, each line must be in this format: ////////////////////////// この `cut` コマンドは、各行の11文字目から20文字目だけを抽出します。 また、この `tail` コマンドは、最初の2行（フィールドヘッダと、下線のアスキーアート）を読み飛ばします。 -この処理の結果は、重複を排除するためパイプで `uniq` コマンドへ送られた上で、 `AUTHORS` ファイルへ保存されます。 +この処理の結果は、重複を排除するためパイプで `sort` コマンドと `uniq` コマンドへ送られた上で、 `AUTHORS` ファイルへ保存されます。 次のステップは手作業です。git-tfs でこのファイルを利用するには、各行は次のフォーマットに従っている必要があります。 [source,text] diff --git a/book/10-git-internals/sections/objects.asc b/book/10-git-internals/sections/objects.asc index eded9f1f..8ee1e19e 100644 --- a/book/10-git-internals/sections/objects.asc +++ b/book/10-git-internals/sections/objects.asc @@ -375,9 +375,13 @@ fdf4fc3344e67ab068f836878b6c4951e3b15f3d ---- ////////////////////////// +You will get a different hash value because of different creation time and author data. +Replace commit and tag hashes with your own checksums further in this chapter. Now you can look at your new commit object with `cat-file`: ////////////////////////// -これで、`cat-file` コマンドを使って、新しいコミットオブジェクトを見られるようになりました。 +作成時間と作成者データが異なるため、違うハッシュ値が表示されます。 +この章ではコミットとタグのハッシュを独自のチェックサムに置き換えます。 +これで、`cat-file` コマンドを使って、新しいコミットオブジェクトを見られるようになります。 [source,console] ---- diff --git a/book/10-git-internals/sections/packfiles.asc b/book/10-git-internals/sections/packfiles.asc index 416688dc..88f28271 100644 --- a/book/10-git-internals/sections/packfiles.asc +++ b/book/10-git-internals/sections/packfiles.asc @@ -38,6 +38,7 @@ Gitの興味深い機能を実際に見てみるために、幾つか大きな [source,console] ---- $ curl https://raw.githubusercontent.com/mojombo/grit/master/lib/grit/repo.rb > repo.rb +$ git checkout master $ git add repo.rb $ git commit -m 'added repo.rb' [master 484a592] added repo.rb @@ -109,10 +110,10 @@ $ git cat-file -s b042a60ef7dff760008df33cee372b945b6e884e ---- ////////////////////////// -You have two nearly identical 22K objects on your disk. +You have two nearly identical 22K objects on your disk (each compressed to approximately 7K). Wouldn't it be nice if Git could store one of them in full but then the second object only as the delta between it and the first? ////////////////////////// -これだと、ディスク上にほとんど同じ内容の22Kバイトのオブジェクトが2つあることになります。 +これだと、ディスク上にほとんど同じ内容の22Kバイトのオブジェクトが2つあることになります（それぞれ約7Kバイトに圧縮されます）。 もし、Gitが2つのうち1つは完全に格納し、2つめのオブジェクトは1つめとの差分のみを格納できたら、素晴らしいと思いませんか？ ////////////////////////// @@ -164,14 +165,14 @@ Because you never added them to any commits, they're considered dangling and are The other files are your new packfile and an index. The packfile is a single file containing the contents of all the objects that were removed from your filesystem. The index is a file that contains offsets into that packfile so you can quickly seek to a specific object. -What is cool is that although the objects on disk before you ran the `gc` were collectively about 22K in size, the new packfile is only 7K. -You've cut your disk usage by ⅔ by packing your objects. +What is cool is that although the objects on disk before you ran the `gc` were collectively about 15K in size, the new packfile is only 7K. +You've cut your disk usage by half by packing your objects. ////////////////////////// 残りの2つのファイルが、新しく作られたpackfileとインデックスです。 packfileには、ファイルシステムから削除されたすべてのオブジェクトの内容が1つのファイルに含まれています。 インデックスには、特定のオブジェクトを速くシークできるように、packfile中でのオフセットが記録されています。 -素晴らしいことに、`gc` を実行する前のディスク上のオブジェクトは合計で約22Kバイトあったのに対して、新しいパックファイルはたった7Kバイトになっています。 -オブジェクトをパックすることで、ディスク使用量の⅔を削減できたのです。 +素晴らしいことに、`gc` を実行する前のディスク上のオブジェクトは合計で約15Kバイトあったのに対して、新しいパックファイルはたった7Kバイトになっています。 +オブジェクトをパックすることで、ディスク使用量の半分を削減できたのです。 ////////////////////////// How does Git do this?