Merge upstream changes into ja

Merge commit '20fce7f75ff641240e924884c876ed61ee048395'

Conflicts:
	book/preface.asc

Author: harupong

CONTRIBUTING.md

@@ -0,0 +1,37 @@
+# Contributing to Pro Git (2nd Edition)
+
+
+## Licensing
+
+By opening a pull request to this repository, you agree to provide your work under the [project license](LICENSE.asc).
+Also, you agree to grant such license of your work as is required for the purposes of future print editions to @ben and @schacon.
+Should your changes appear in a printed edition, you'll be included in the [contributors list](book/contributors.asc).
+
+## Small Corrections
+
+Errata and basic clarifications will be accepted if we agree that they improve the content. You can also open an issue so we can figure out how or if it needs to be addressed.
+
+If you've never done this before, the [flow guide](https://guides.github.com/introduction/flow/) might be useful.
+
+## Large Rewrites
+
+Open an issue for discussion before you start. These changes tend to be very subjective, often only clarifying things for some small percentage of people and it's rarely worth the time to accept them. Professional copy editors have already reviewed this content multiple times so while you may have somewhat better taste and grammar than we do it's unlikely that your prose is going to be *so* much better that it's worth changing vast swaths of text.
+
+## Figures
+
+The images in this book were generated using [Sketch 3](http://bohemiancoding.com/sketch/), with the [included sketchbook file](diagram-source/progit.sketch).
+
+To add a figure:
+
+1. Add a page to the sketchbook. Try to use the included symbols wherever possible.
+1. Add a "slice" to your page. Give it a name that matches the destination PNG filename, relative from the root of the source directory.
+1. Make sure your slice is set to export at 3x size.
+
+
+## Translations
+
+Translations to other languages are highly encouraged but handled a little differently than the first edition. We now keep each translation in a separate repository and automatically build the output files through Atlas. This was something that was really difficult in the last edition.
+
+Since each translation is a different repository, we can also have different maintainers for each project. The Pro Git team simply pulls them in and builds them for the translation teams. To get automatic builds, translations repositories will have to be under the [`progit` organization on GitHub](https://github.com/progit).
+
+You can find out information on all the current translations and information on how to start your own at http://progit.org/translations.

README.asc

@@ -8,15 +8,7 @@ Like the first edition, the second edition of Pro Git is open source under a Cre
 
 A couple of things have changed since open sourcing the first edition. For one, we've moved from Markdown to the amazing Asciidoc format for the text of the book. We've also moved to using O'Reilly's https://atlas.oreilly.com[Atlas platform] for generating continuous builds of the book so all major formats are always available in every language.
 
-We've also moved to keeping the translations in seperate repositories rather than subdirectories of the English repository. See the Translations section for more information.
-
-== Contributing
-
-To contribute errata or new content to this repository, you will need to open up a Pull Request on GitHub. It is generally a good idea before doing anything major to open an issue and make sure your work will get accepted.
-
-Errata and basic clarifications will be accepted if we agree that they improve the content. You can also open an issue so we can figure out how or if it needs to be addressed.
-
-Please refrain from making sweeping copy edit changes as they tend to not get accepted and we don't want you wasting your time. These changes tend to be very subjective, often only clarifying things for some small percentage of people and it's rarely worth the time to accept them. Professional copy editors have already reviewed this content multiple times so while you may have somewhat better taste and grammar than we do it's unlikely that your prose is going to be *so* much better that it's worth changing vast swaths of text.
+We've also moved to keeping the translations in separate repositories rather than subdirectories of the English repository. See the Translations section for more information.
 
 == How To Generate the Book
 
@@ -43,20 +35,6 @@ Converting to PDF...
 
 This uses the `asciidoctor`, `asciidoctor-pdf` and `asciidoctor-epub` projects.
 
-== Translations
-
-Translations to other languages are highly encouraged but handled a little differently than the first edition. We now keep each translation in a seperate repository and automatically build the output files through Atlas. This was something that was really difficult in the last edition.
-
-Since each translation is a different repository, we can also have different maintainers for each project. The Pro Git team simply pulls them in and builds them for the translation teams. To get automatic builds, translations repositories will have to be under the https://github.com/progit[progit organization on GitHub].
-
-You can find out information on all the current translations and information on how to start your own at: http://progit.org/translations[].
-
-== Figures
-
-The images in this book were generated using http://bohemiancoding.com/sketch/[Sketch 3], with the link:diagram-source/progit.sketch[included sketchbook file].
-
-To add a figure:
+== Contributing
 
-. Add a page to the sketchbook. Try to use the included symbols wherever possible.
-. Add a ``slice'' to your page. Give it a name that matches the destination PNG filename, relative from the root of the source directory.
-. Make sure your slice is set to export at 3x size.
+If you'd like to help out by making a change or contributing a translation, take a look at the link:CONTRIBUTING.md[contributor's guide].

book/03-git-branching/sections/remote-branches.asc

@@ -85,7 +85,7 @@ If you didn't want it to be called `serverfix` on the remote, you could instead
 ====
 If you're using an HTTPS URL to push over, the Git server will ask you for your username and password for authentication. By default it will prompt you on the terminal for this information so the server can tell if you're allowed to push.
 
-If you don't want to type it every single time you push, you can set up a ``credential cache''. The simplest is just to keep it in memory for a few mintues, which you can easily set up by running `git config --global credential.helper cache`.
+If you don't want to type it every single time you push, you can set up a ``credential cache''. The simplest is just to keep it in memory for a few minutes, which you can easily set up by running `git config --global credential.helper cache`.
 
 For more information on the various credential caching options available, see <<_credential_caching>>.
 ====

book/04-git-server/sections/git-on-a-server.asc

@@ -70,7 +70,7 @@ It's important to note that this is literally all you need to do to run a useful
 You're ready to go – nothing else needed.
 
 In the next few sections, you'll see how to expand to more sophisticated setups.
-This discussion will include not having to create user accounts for each user, adding public read access to repositories, setting up web UIs, using the Gitosis tool, and more.
+This discussion will include not having to create user accounts for each user, adding public read access to repositories, setting up web UIs and more.
 However, keep in mind that to collaborate with a couple of people on a private project, all you _need_ is an SSH server and a bare repository.
 
 ==== Small Setups

book/04-git-server/sections/setting-up-server.asc

@@ -4,7 +4,7 @@
 Let's walk through setting up SSH access on the server side.
 In this example, you'll use the `authorized_keys` method for authenticating your users.
 We also assume you're running a standard Linux distribution like Ubuntu.
-First, you create a 'git' user and a `.ssh` directory for that user.
+First, you create a `git` user and a `.ssh` directory for that user.
 
 [source,console]
 ----
@@ -52,7 +52,7 @@ Initialized empty Git repository in /opt/git/project.git/
 
 Then, John, Josie, or Jessica can push the first version of their project into that repository by adding it as a remote and pushing up a branch.
 Note that someone must shell onto the machine and create a bare repository every time you want to add a project.
-Let's use `gitserver` as the hostname of the server on which you've set up your 'git' user and repository.
+Let's use `gitserver` as the hostname of the server on which you've set up your `git` user and repository.
 If you're running it internally, and you set up DNS for `gitserver` to point to that server, then you can use the commands pretty much as is (assuming that `myproject` is an existing project with files in it):
 
 [source,console]
@@ -79,10 +79,10 @@ $ git push origin master
 
 With this method, you can quickly get a read/write Git server up and running for a handful of developers.
 
-You should note that currently all these users can also log into the server and get a shell as the ``git'' user. If you want to restrict that, you will have to change the shell to something else in the `passwd` file.
+You should note that currently all these users can also log into the server and get a shell as the `git` user. If you want to restrict that, you will have to change the shell to something else in the `passwd` file.
 
-You can easily restrict the 'git' user to only doing Git activities with a limited shell tool called `git-shell` that comes with Git.
-If you set this as your 'git' user's login shell, then the 'git' user can't have normal shell access to your server.
+You can easily restrict the `git` user to only doing Git activities with a limited shell tool called `git-shell` that comes with Git.
+If you set this as your `git` user's login shell, then the `git` user can't have normal shell access to your server.
 To use this, specify `git-shell` instead of bash or csh for your user's login shell.
 To do so, you must first add `git-shell` to `/etc/shells` if it's not already there:
 
@@ -100,7 +100,7 @@ Now you can edit the shell for a user using `chsh <username>`:
 $ sudo chsh git  # and enter the path to git-shell, usually: /usr/bin/git-shell
 ----
 
-Now, the 'git' user can only use the SSH connection to push and pull Git repositories and can't shell onto the machine.
+Now, the `git` user can only use the SSH connection to push and pull Git repositories and can't shell onto the machine.
 If you try, you'll see a login rejection like this:
 
 [source,console]
@@ -112,6 +112,6 @@ Connection to gitserver closed.
 ----
 
 Now Git network commands will still work just fine but the users won't be able to get a shell.
-As the output states, you can also set up a directory in the ``git'' user's home directory that customizes the `git-shell` command a bit.
+As the output states, you can also set up a directory in the `git` user's home directory that customizes the `git-shell` command a bit.
 For instance, you can restrict the Git commands that the server will accept or you can customize the message that users see if they try to SSH in like that.
 Run `git help shell` for more information on customizing the shell.(((git commands, help)))

book/04-git-server/sections/smart-http.asc

@@ -16,7 +16,7 @@ $ a2enmod cgi alias env
 
 This also enables the `mod_cgi`, `mod_alias`, and `mod_env` modules, which are all needed for this to work properly.
 
-Next we need to add some things to the Apache configuration to run the `git http-backend` as the handler for anything coming into the `/git` path of your web server.
+Next we need to add some things to the Apache configuration to run the `git-http-backend` as the handler for anything coming into the `/git` path of your web server.
 
 [source,console]
 ----
@@ -60,7 +60,7 @@ $ htdigest -c /opt/git/.htpasswd "Git Access" schacon
 
 There are tons of ways to have Apache authenticate users, you'll have to choose and implement one of them. This is just the simplest example we could come up with. You'll also almost certainly want to set this up over SSL so all this data is encrypted.
 
-We don't want to go too far down the rabbit hole of Apache configuration specifics, since you could well be using a different server or have different authenication needs. The idea is that Git comes with a CGI called `git http-backend` that when invoked will do all the negotiation to send and receive data over HTTP. It does not implement any authentication itself, but that can easily be controlled at the layer of the web server that invokes it. You can do this with nearly any CGI-capable web server, so go with the one that you know best.
+We don't want to go too far down the rabbit hole of Apache configuration specifics, since you could well be using a different server or have different authentication needs. The idea is that Git comes with a CGI called `git-http-backend` that when invoked will do all the negotiation to send and receive data over HTTP. It does not implement any authentication itself, but that can easily be controlled at the layer of the web server that invokes it. You can do this with nearly any CGI-capable web server, so go with the one that you know best.
 
 [NOTE]
 ====

book/05-distributed-git/sections/contributing.asc

@@ -41,8 +41,8 @@ The Git project provides a document that lays out a number of good tips for crea
 First, you don't want to submit any whitespace errors.
 Git provides an easy way to check for this – before you commit, run `git diff --check`, which identifies possible whitespace errors and lists them for you.
 
-.Output of `git diff -check`.
-image::images/git-diff-check.png[Output of `git diff -check`.]
+.Output of `git diff --check`.
+image::images/git-diff-check.png[Output of `git diff --check`.]
 
 If you run that command before committing, you can tell if you're about to commit whitespace issues that may annoy other developers.
 

book/06-github/sections/1-setting-up-account.asc

@@ -42,7 +42,7 @@ From there, click the "`Add an SSH key`" button, give your key a name, paste the
 
 [NOTE]
 ====
-Be sure to name your SSH key something you can remember. You can name each of your keys (eg, "My Laptop" or "Work Account") so that if you need to revoke a key later, you can easily tell which one you're looking for.
+Be sure to name your SSH key something you can remember. You can name each of your keys (e.g. "My Laptop" or "Work Account") so that if you need to revoke a key later, you can easily tell which one you're looking for.
 ====
 
 [[_personal_avatar]]

book/06-github/sections/2-contributing.asc

@@ -84,7 +84,7 @@ void loop() {
 }
 
 $ git commit -a -m 'three seconds is better' <5>
-[master 5ca509d] three seconds is better
+[slow-blink 5ca509d] three seconds is better
  1 file changed, 2 insertions(+), 2 deletions(-)
 
 $ git push origin slow-blink <6>
@@ -270,7 +270,7 @@ image::images/mentions-02-render.png[PR references rendered]
 
 Notice that the full GitHub URL we put in there was shortened to just the information needed.
 
-Now if Tony goes back and closes out the original Pull Request, we can see that by mentioning it in the new one, GitHub has automatically created a trackback event in the Pull Request timeline. This means that anyone who visits this Pull Request and sees that it is closed can easily link back to the one that superceded it. The link will look something like <<_pr_closed>>.
+Now if Tony goes back and closes out the original Pull Request, we can see that by mentioning it in the new one, GitHub has automatically created a trackback event in the Pull Request timeline. This means that anyone who visits this Pull Request and sees that it is closed can easily link back to the one that superseded it. The link will look something like <<_pr_closed>>.
 
 [[_pr_closed]]
 .Cross references rendered in a Pull Request.

book/06-github/sections/3-maintaining.asc

@@ -60,7 +60,7 @@ Now that you have a project with some code in it and maybe even a few collaborat
 
 Pull Requests can either come from a branch in a fork of your repository or they can come from another branch in the same repository. The only difference is that the ones in a fork are often from people where you can't push to their branch and they can't push to yours, whereas with internal Pull Requests generally both parties can access the branch.
 
-For these examples, let's assume you are ``tonychacon'' and you've created a new Arudino code project named ``fade''.
+For these examples, let's assume you are ``tonychacon'' and you've created a new Arduino code project named ``fade''.
 
 [[_email_notifications]]
 ===== Email Notifications
@@ -93,7 +93,7 @@ image::images/maint-03-email-resp.png[Email response]
 
 Once the code is in a place you like and want to merge it in, you can either pull the code down and merge it locally, either with the `git pull <url> <branch>` syntax we saw earlier, or by adding the fork as a remote and fetching and merging.
 
-If the merge is trivial, you can also just hit the ``Merge'' buton on the GitHub site. This will do a ``non-fast-forward'' merge, creating a merge commit even if a fast-forward merge was possible. This means that no matter what, every time you hit the merge button, a merge commit is created. As you can see in <<_merge_button>>, GitHub gives you all of this information if you click the hint link.
+If the merge is trivial, you can also just hit the ``Merge'' button on the GitHub site. This will do a ``non-fast-forward'' merge, creating a merge commit even if a fast-forward merge was possible. This means that no matter what, every time you hit the merge button, a merge commit is created. As you can see in <<_merge_button>>, GitHub gives you all of this information if you click the hint link.
 
 [[_merge_button]]
 .Merge button and instructions for merging a Pull Request manually.
@@ -245,7 +245,7 @@ Web notifications only exist on GitHub and you can only check them on GitHub. If
 .Notification center.
 image::images/maint-08-notifications-page.png[Notification center]
 
-If you click on that, you will see a list of all the items you have been notified about, grouped by project. You can filter to the notifications of a specific project by clicking on it's name in the left hand sidebar. You can also acknowledge the notification by clicking the checkmark icon next to any notification, or acknowledge _all_ of the notifictions in a project by clicking the checkmark at the top of the group. There is also a mute button next to each checkmark that you can click to not receive any further notifications on that item.
+If you click on that, you will see a list of all the items you have been notified about, grouped by project. You can filter to the notifications of a specific project by clicking on it's name in the left hand sidebar. You can also acknowledge the notification by clicking the checkmark icon next to any notification, or acknowledge _all_ of the notifications in a project by clicking the checkmark at the top of the group. There is also a mute button next to each checkmark that you can click to not receive any further notifications on that item.
 
 All of these tools are very useful for handling large numbers of notifications. Many GitHub power users will simply turn off email notifications entirely and manage all of their notifications through this screen.