Merge pull request #836 from Onizuka89/master

no-NB chapter 1 translated
progit · Aug 6, 2014 · 10f3474 · 10f3474
2 parents 8d83e96 + 9cd87e7
commit 10f3474
Show file tree

Hide file tree

Showing 10 changed files with 805 additions and 681 deletions.
diff --git a/makeebooks b/makeebooks
@@ -83,6 +83,11 @@ ARGV.each do |lang|
       figure_title = 'Obrázek'
       book_title = 'Pro Git — profesionální správa verzí'
       comments = 'Licence: Creative Commons Attribution-Non Commercial-Share Alike 3.0 license'
+    elsif lang == "no-nb"
+        figure_title = 'Figur'
+        book_title = 'Pro Git - profesjonell versjonkontroll'
+        comments = 'Lisens: Creative Commons Attribution-Non Commercial-Share Alike 3.0 license'
+
     end
 
     book_content = %(<html xmlns="http://www.w3.org/1999/xhtml"><head><title>#{book_title}</title></head><body>)

diff --git a/no-nb/01-introduction/01-chapter1.markdown b/no-nb/01-introduction/01-chapter1.markdown
diff --git a/no-nb/02-git-basics/01-chapter2.markdown b/no-nb/02-git-basics/01-chapter2.markdown
diff --git a/no-nb/03-git-branching/01-chapter3.markdown b/no-nb/03-git-branching/01-chapter3.markdown
diff --git a/no-nb/04-git-server/01-chapter4.markdown b/no-nb/04-git-server/01-chapter4.markdown
diff --git a/no-nb/05-distributed-git/01-chapter5.markdown b/no-nb/05-distributed-git/01-chapter5.markdown
@@ -22,7 +22,7 @@ This workflow is attractive to a lot of people because it’s a paradigm that ma
 
 ### Integration-Manager Workflow ###
 
-Because Git allows you to have multiple remote repositories, it’s possible to have a workflow where each developer has write access to their own public repository and read access to everyone else’s. This scenario often includes a canonical repository that represents the "official" project. To contribute to that project, you create your own public clone of the project and push your changes to it. Then, you can send a request to the maintainer of the main project to pull in your changes. They can add your repository as a remote, test your changes locally, merge them into their branch, and push back to their repository. The process works as follow (see Figure 5-2):
+Because Git allows you to have multiple remote repositories, it’s possible to have a workflow where each developer has write access to their own public repository and read access to everyone else’s. This scenario often includes a canonical repository that represents the "official" project. To contribute to that project, you create your own public clone of the project and push your changes to it. Then, you can send a request to the maintainer of the main project to pull in your changes. They can add your repository as a remote, test your changes locally, merge them into their branch, and push back to their repository. The process works as follows (see Figure 5-2):
 
 1. The project maintainer pushes to their public repository.
 2. A contributor clones that repository and makes changes.
@@ -48,7 +48,7 @@ This is a variant of a multiple-repository workflow. It’s generally used by hu
 Insert 18333fig0503.png
 Figure 5-3. Benevolent dictator workflow.
 
-This kind of workflow isn’t common but can be useful in very big projects or in highly hierarchical environments, because as it allows the project leader (the dictator) to delegate much of the work and collect large subsets of code at multiple points before integrating them.
+This kind of workflow isn’t common but can be useful in very big projects or in highly hierarchical environments, as it allows the project leader (the dictator) to delegate much of the work and collect large subsets of code at multiple points before integrating them.
 
 These are some commonly used workflows that are possible with a distributed system like Git, but you can see that many variations are possible to suit your particular real-world workflow. Now that you can (I hope) determine which workflow combination may work for you, I’ll cover some more specific examples of how to accomplish the main roles that make up the different flows.
 
@@ -174,7 +174,7 @@ John has a reference to the changes Jessica pushed up, but he has to merge them
 The merge goes smoothly — John’s commit history now looks like Figure 5-5.
 
 Insert 18333fig0505.png
-Figure 5-5. John’s repository after merging origin/master.
+Figure 5-5. John’s repository after merging `origin/master`.
 
 Now, John can test his code to make sure it still works properly, and then he can push his new merged work up to the server:
 
@@ -215,7 +215,7 @@ Jessica thinks her topic branch is ready, but she wants to know what she has to
 
 	    removed invalid default value
 
-Now, Jessica can merge her topic work into her master branch, merge John’s work (`origin/master`) into her `master` branch, and then push back to the server again. First, she switches back to her master branch to integrate all this work:
+Now, Jessica can merge her topic work into her `master` branch, merge John’s work (`origin/master`) into her `master` branch, and then push back to the server again. First, she switches back to her `master` branch to integrate all this work:
 
 	$ git checkout master
 	Switched to branch "master"
@@ -230,7 +230,7 @@ She can merge either `origin/master` or `issue54` first — they’re both upstr
 	 lib/simplegit.rb |    6 +++++-
 	 2 files changed, 6 insertions(+), 1 deletions(-)
 
-No problems occur; as you can see it, was a simple fast-forward. Now Jessica merges in John’s work (`origin/master`):
+No problems occur; as you can see, it was a simple fast-forward. Now Jessica merges in John’s work (`origin/master`):
 
 	$ git merge origin/master
 	Auto-merging lib/simplegit.rb
@@ -255,7 +255,7 @@ Each developer has committed a few times and merged each other’s work successf
 Insert 18333fig0510.png
 Figure 5-10. Jessica’s history after pushing all changes back to the server.
 
-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. The general sequence is something like that shown in Figure 5-11.
+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. The general sequence is something like that shown in Figure 5-11.
 
 Insert 18333fig0511.png
 Figure 5-11. General sequence of events for a simple multiple-developer Git workflow.
@@ -359,12 +359,12 @@ Finally, she merges John’s work into her own `featureA` branch:
 Jessica wants to tweak something, so she commits again and then pushes this back up to the server:
 
 	$ git commit -am 'small tweak'
-	[featureA ed774b3] small tweak
+	[featureA 774b3ed] small tweak
 	 1 files changed, 1 insertions(+), 1 deletions(-)
 	$ git push origin featureA
 	...
 	To jessica@githost:simplegit.git
-	   3300904..ed774b3  featureA -> featureA
+	   3300904..774b3ed  featureA -> featureA
 
 Jessica’s commit history now looks something like Figure 5-13.
 
@@ -481,7 +481,7 @@ The workflow is similar to the previous use case — you create topic branches f
 	$ (work)
 	$ git commit
 
-Now you have two commits that you want to send to the mailing list. You use `git format-patch` to generate the mbox-formatted files that you can e-mail to the list — it turns each commit into an e-mail message with the first line of the commit message as the subject and the rest of the message plus the patch that the commit introduces as the body. The nice thing about this is that applying a patch from an e-mail generated with `format-patch` preserves all the commit information properly, as you’ll see more of in the next section when you apply these commits:
+Now you have two commits that you want to send to the mailing list. You use `git format-patch` to generate the mbox-formatted files that you can e-mail to the list — it turns each commit into an e-mail message with the first line of the commit message as the subject and the rest of the message plus the patch that the commit introduces as the body. The nice thing about this is that applying a patch from an e-mail generated with `format-patch` preserves all the commit information properly, as you’ll see more of in the next section when you apply these patches:
 
 	$ git format-patch -M origin/master
 	0001-add-limit-to-log-function.patch
@@ -532,7 +532,26 @@ First, you need to set up the imap section in your `~/.gitconfig` file. You can
 	  sslverify = false
 
 If your IMAP server doesn’t use SSL, the last two lines probably aren’t necessary, and the host value will be `imap://` instead of `imaps://`.
-When that is set up, you can use `git send-email` to place the patch series in the Drafts folder of the specified IMAP server:
+When that is set up, you can use `git imap-send` to place the patch series in the Drafts folder of the specified IMAP server:
+
+	$ cat *.patch |git imap-send
+	Resolving imap.gmail.com... ok
+	Connecting to [74.125.142.109]:993... ok
+	Logging in...
+	sending 2 messages
+	100% (2/2) done
+
+At this point, you should be able to go to your Drafts folder, change the To field to the mailing list you’re sending the patch to, possibly CC the maintainer or person responsible for that section, and send it off.
+
+You can also send the patches through an SMTP server. As before, you can set each value separately with a series of `git config` commands, or you can add them manually in the sendemail section in your `~/.gitconfig` file:
+
+	[sendemail]
+	  smtpencryption = tls
+	  smtpserver = smtp.gmail.com
+	  smtpuser = user@gmail.com
+	  smtpserverport = 587
+
+After this is done, you can use `git send-email` to send your patches:
 
 	$ git send-email *.patch
 	0001-added-limit-to-log-function.patch
@@ -559,8 +578,6 @@ Then, Git spits out a bunch of log information looking something like this for e
 
 	Result: OK
 
-At this point, you should be able to go to your Drafts folder, change the To field to the mailing list you’re sending the patch to, possibly CC the maintainer or person responsible for that section, and send it off.
-
 ### Summary ###
 
 This section has covered a number of common workflows for dealing with several very different types of Git projects you’re likely to encounter and introduced a couple of new tools to help you manage this process. Next, you’ll see how to work the other side of the coin: maintaining a Git project. You’ll learn how to be a benevolent dictator or integration manager.
@@ -576,7 +593,7 @@ As you’ll remember, you can create the branch based off your master branch lik
 
 	$ git branch sc/ruby_client master
 
-Or, if you want to also switch to it immediately, you can use the `checkout -b` option:
+Or, if you want to also switch to it immediately, you can use the `checkout -b` command:
 
 	$ git checkout -b sc/ruby_client master
 
@@ -594,7 +611,7 @@ If you received the patch from someone who generated it with the `git diff` or a
 
 This modifies the files in your working directory. It’s almost identical to running a `patch -p1` command to apply the patch, although it’s more paranoid and accepts fewer fuzzy matches than patch. It also handles file adds, deletes, and renames if they’re described in the `git diff` format, which `patch` won’t do. Finally, `git apply` is an "apply all or abort all" model where either everything is applied or nothing is, whereas `patch` can partially apply patchfiles, leaving your working directory in a weird state. `git apply` is overall much more paranoid than `patch`. It won’t create a commit for you — after running it, you must stage and commit the changes introduced manually.
 
-You can also use git apply to see if a patch applies cleanly before you try actually applying it — you can run `git apply --check` with the patch:
+You can also use `git apply` to see if a patch applies cleanly before you try actually applying it — you can run `git apply --check` with the patch:
 
 	$ git apply --check 0001-seeing-if-this-helps-the-gem.patch
 	error: patch failed: ticgit.gemspec:1
@@ -615,7 +632,7 @@ To apply a patch generated by `format-patch`, you use `git am`. Technically, `gi
 
 	Limit log functionality to the first 20
 
-This is the beginning of the output of the format-patch command that you saw in the previous section. This is also a valid mbox e-mail format. If someone has e-mailed you the patch properly using git send-email, and you download that into an mbox format, then you can point git am to that mbox file, and it will start applying all the patches it sees. If you run a mail client that can save several e-mails out in mbox format, you can save entire patch series into a file and then use git am to apply them one at a time.
+This is the beginning of the output of the format-patch command that you saw in the previous section. This is also a valid mbox e-mail format. If someone has e-mailed you the patch properly using `git send-email`, and you download that into an mbox format, then you can point `git am` to that mbox file, and it will start applying all the patches it sees. If you run a mail client that can save several e-mails out in mbox format, you can save entire patch series into a file and then use `git am` to apply them one at a time.
 
 However, if someone uploaded a patch file generated via `format-patch` to a ticketing system or something similar, you can save the file locally and then pass that file saved on your disk to `git am` to apply it: