Correcties zwaar geinspireerd door @jnavilla

.travis.yml

@@ -1,33 +1,34 @@
 language: ruby
+sudo: false
 git:
   depth: false
 cache: bundler
 before_install:
-- bundle install
-after_success:
-- script/tag_on_master
+ - wget https://raw.githubusercontent.com/progit/progit2-pub/master/bootstrap.sh
+ - sh bootstrap.sh
 script: bundle exec rake book:build
-env:
-  secure: "O+YCTDgLfCYAJjjOv2sApDRV5NJe6pkhiYIkORFuf2flO8HE72fEtDRpSWh1vulnIH6AjRK2jH7C8qA3MVbUO8D0io+Ha+vnbMXIp1JPCptcJNEkJrW13VTR66SWOzsgLp3mCrIC+YdE2JoYWGcnDsRMQwdnrWnxBzSOd22ZKzU="
-
-before_deploy: bundle install && bundle exec rake book:build
+after_success: bundle exec rake book:tag
 deploy:
   provider: releases
+  file_glob: true
   file:
-  - progit.epub
-  - progit.mobi
-  - progit.pdf
+  - progit*.epub
+  - progit*.mobi
+  - progit*.pdf
   skip_cleanup: true
   on:
     tags: true
-  api-key:
-    secure: "l3XdupX6dT48IoTieJXrd7Yx8+KhiR2QYrNrDzT6RKxA7UyXGSP/axsVerg7OjKfIHWZgDJRVzcc2RswE+Xjw9sOY8r2h2q9uCwj8G0EqtFbtgGK0La5LB0euh0tNJN8GLFj1OdSZGY7dWWK88GXeHCua2WSify0V79R4ClIM+s="
+  api-key: $GITHUB_API_TOKEN
 branches:
   only:
   - master
   - /^2\.1(\.\d+)+$/
 
+addons:
+  apt:
+    packages:
+      - epubcheck
 notifications:
   email:
     on_success: never
-    on_failure: always
+    on_failure: always

C-git-commands.asc

@@ -116,7 +116,8 @@ Dit kan het verschil zijn tussen je werk omgeving en je staging area (`git diff`
 
 We kijken eerst naar de basis gebruiken van `git diff` in <<ch02-git-basics-chapter#_git_diff_staged>>, waar we laten zien hoe je kunt zien welke wijzigingen er zijn gestaged en welke nog niet.
 
-We gebruiken het om te kijken of er mogelijke witruimte-problemen zijn voor we committen met de `--check` optie in <<ch05-distributed-git#commit_guidelines>>.
+We gebruiken het om te kijken of er mogelijke witruimte-problemen zijn voor we committen met de `--check` optie in
+<<ch05-distributed-git#_commit_guidelines>>.
 
 We zien hoe we de verschillen tussen branches efficiënter kunnen controleren met de `git diff A...B` syntax in <<ch05-distributed-git#_what_is_introduced>>.
 

README.asc

@@ -1,3 +1,4 @@
+image:https://travis-ci.org/progit/progit2-nl.svg?branch=master["Build Status", link="https://travis-ci.org/progit/progit2-nl"]
 ////
 Laatst bijgewerkt van progit/progit2 referentie: 7836cfed
 ////

book/02-git-basics/sections/viewing-history.asc

@@ -267,7 +267,7 @@ De laatste echt handige optie om aan `git log` als filter mee te geven is een pa
 Als je een directory of bestandsnaam opgeeft, kun je de log output limiteren tot commits die een verandering introduceren op die bestanden.
 Dit is altijd de laatste optie en wordt over het algemeen vooraf gegaan door dubbele streepjes (`--`) om de paden van de opties te scheiden.
 
-In <<limit_options>> laten we deze en een paar andere veel voorkomende opties zien als referentie.
+In <<rlimit_options>> laten we deze en een paar andere veel voorkomende opties zien als referentie.
 
 [[rlimit_options]]
 .Opties om de uitvoer van `git log` te beperken

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

@@ -166,7 +166,7 @@ In <<_pr_final>> is te zien dat de oude code commentaar is ingeklapt in de bijge
 
 Het toevoegen van commits in een bestaande Pull Request veroorzaakt geen notificatie, dus als Tony eenmaal zijn correcties heeft gepusht besluit hij om een commentaar achter te laten om de project eigenaar te informeren dat hij de gevraagde wijziging gemaakt heeft.
 
-[[r_pr_final]]
+[[_pr_final]]
 .Pull Request finaal
 image::images/blink-06-final.png[PR finaal]
 

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

@@ -274,7 +274,6 @@ De twee keuzes zijn om de berichten via ``Email'' en via ``Web'' te ontvangen en
 
 Web meldingen bestaan alleen binnen GitHub en je kunt ze alleen op GitHub controleren.
 Als je deze optie geselecteerd hebt in je voorkeuren en een bericht wordt voor je gemaakt, zie je een kleine blauwe stip boven je meldingen ikoon boven in je scherm zoals getoond in <<_not_center>>.
-  icon at the top of your screen as seen in <<r_not_center>>.
 
 [[_not_center]]
 .Notification center.

book/06-github/sections/5-scripting.asc

@@ -45,7 +45,7 @@ Je geeft een URL op en GitHub zal een HTTP payload posten op die URL bij elke ge
 
 Hoe dit globaal werkt is dat je een kleine web service kunt opzetten die naar een GitHub hook payload luistert en dan iets met de gegevens doet als het is ontvangen.
 
-Om een hook aan te zetten, klik je de ``Add webhook'' knop in <<r_services_hooks>>.
+Om een hook aan te zetten, klik je de ``Add webhook'' knop in <<_services_hooks>>.
 Dit leidt je naar een pagina die eruit ziet als <<_web_hook>>.
 
 [[_web_hook]]

book/07-git-tools/sections/credentials.asc

@@ -50,7 +50,7 @@ Hier is hoe een `.gitconfig` eruit zou kunnen zien als je een credentials bestan
 
 [source,ini]
 ----
-[credential]
+ [credential]
     helper = store --file /mnt/thumbdrive/.git-credentials
     helper = cache --timeout 30000
 ----

book/07-git-tools/sections/rerere.asc

@@ -187,7 +187,7 @@ Als we nu het bestand bekijken zullen we zien dat het al is opgelost, er staan g
 def hello
   puts 'hola mundo'
 end
------
+----
 
 Ook zal `git diff` je laten zien hoe het automatisch opnieuw was opgelost:
 

book/07-git-tools/sections/submodules.asc

@@ -62,7 +62,7 @@ Dit is een configuratie bestand waarin de relatie wordt vastgelegd tussen de URL
 
 [source,ini]
 ----
-[submodule "DbConnector"]
+ [submodule "DbConnector"]
 	path = DbConnector
 	url = https://github.com/chaconinc/DbConnector
 ----

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

@@ -318,7 +318,7 @@ Als je `git archive` uitvoert, zal de inhoud van dat bestand er zo uit zien:
 $ git archive HEAD | tar xCf ../deployment-testing -
 $ cat ../deployment-testing/LAST_COMMIT
 Last commit date: Tue Apr 21 08:38:48 2009 -0700 by Scott Chacon
----
+----
 
 De vervangingen kunnen bijvoorbeeld het commit bericht en elke `git note` omvatten, en `git log` kan eenvoudige word-wrapping uitvoeren:
 

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

@@ -21,7 +21,8 @@ De `update` hook zal eens per gepushte branch uitgevoerd worden en accepteert dr
 * de nieuwe gepushte revisie.
 
 Je hebt ook toegang tot de gebruiker die de push doet als de push via SSH gedaan wordt.
-Als je iedereen hebt toegestaan om connectie te maken als één gebruiker (zoals ``git'') via publieke sleutel authenticatie, dan moet je wellicht die gebruiker een shell wrapper geven die bepaalt welke gebruiker er connectie maakt op basis van de publieke sleutel, en dan een omgevingsvariabele instellen waarin die gebruiker wordt gespecificeerd.
+Als je iedereen hebt toegestaan om connectie te maken als één gebruiker (zoals `git`) via publieke sleutel
+authenticatie, dan moet je wellicht die gebruiker een shell wrapper geven die bepaalt welke gebruiker er connectie maakt op basis van de publieke sleutel, en dan een omgevingsvariabele instellen waarin die gebruiker wordt gespecificeerd.
 Wij gaan er hier van uit dat de gebruiker in de `$USER` omgevingsvariabele staat, dus begint je update script met het verzamelen van alle gegevens die het nodig heeft:
 
 [source,ruby]
@@ -324,7 +325,7 @@ Maar als je bericht het juiste patroon bevat, dan staat Git je toe te committen:
 [source,console]
 ----
 $ git commit -am 'test [ref: 132]'
-[master e05c914] test [ref: 132]
+ [master e05c914] test [ref: 132]
  1 file changed, 1 insertions(+), 0 deletions(-)
 ----
 

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

@@ -68,7 +68,7 @@ image::images/data-model-4.png[Git directory objecten inclusief branch head refe
 
 Als je commando's aanroept zoals `git branch <branchnaam>`, roept Git feitelijk die `update-ref` commando aan om de SHA-1 van de laatste commit op de branch waar je op zit te plaatsten in de referentie die je op dat moment wilt aanmaken.
 
-[[_the_head]]
+[[ref_the_ref]]
 ==== De HEAD
 
 De vraag is nu, als je `git branch <branchnaam>` aanroept, hoe weet Git de SHA-1 van de laatste commit?