diff --git a/CategoricalSyllogism/SinglePremise.mdwn b/CategoricalSyllogism/SinglePremise.mdwn
index 2b7d11e..c1588ba 100644
--- a/CategoricalSyllogism/SinglePremise.mdwn
+++ b/CategoricalSyllogism/SinglePremise.mdwn
@@ -24,7 +24,7 @@
 Such deductions from a single universal premise are _not_ valid for
 the "undotted" `A`, `A*` and `E` relations.
 
-## References
+See also [§13, p.72][#quine].
 
-[1]: Willard van Orman Quine. *Methods of Logic*. Second Edition
+[#quine]: Willard van Orman Quine. *Methods of Logic*. Second Edition
      Revised 1962, Reprinted (with corrections) 1966.

diff --git a/CategoricalSyllogism.mdwn b/CategoricalSyllogism.mdwn
index 6edf702..d8477bd 100644
--- a/CategoricalSyllogism.mdwn
+++ b/CategoricalSyllogism.mdwn
@@ -1,6 +1,7 @@
 # Categorical Syllogism
 
 * [[!traillink  Definitions text="Notation and definitions"]]
+* [[!traillink  SinglePremise text="Deduction from single premise"]]
 * [[!traillink  Conversion text="Conversion of sentences"]]
 * [[!traillink  SyllogismMatrices text="Matrices of valid syllogisms"]]
 
diff --git a/CategoricalSyllogism/Conversion.mdwn b/CategoricalSyllogism/Conversion.mdwn
index 0ce735c..0b6d7f8 100644
--- a/CategoricalSyllogism/Conversion.mdwn
+++ b/CategoricalSyllogism/Conversion.mdwn
@@ -5,7 +5,7 @@
 1. A < B = B > A
 2. A | B = B | A
 3. A <> B = B <> A
-4. A |<> B = B <>| A
+4. A |> B = B <| A
 
 Likewise for the "dotted" variants:
 
@@ -15,11 +15,15 @@ Likewise for the "dotted" variants:
 
 ## Implications
 
-1. A <. B => A <> B
-2. A |. B => A |<> B
+1. `A. implies I`: `A <. B => A <> B`
+2. `.A* implies I`: `B .> A => B <> A`
+3. `E. implies O`: `A |. B => A |> B`
+4. `.E implies O*`: `B .| A => B <| A`
+5. `.E. implies O and O*`: `A .|. B => A |> B`, and `A .|. B => A <| B`
 
-Such implications are valid for the "dotted" variants, but _not_ for the "undotted" ones.
+Such conversions from universal to particular sentences are _not_
+valid for the "undotted" `A`, `A*` and `E` relations.
 
 ## References
 
-[1]: Aristotle, Analytica Priora, Book 1, Chapter 2
+[1]: Aristotle. *Analytica Priora*. Book 1, Chapter 2.
diff --git a/CategoricalSyllogism/Definitions.mdwn b/CategoricalSyllogism/Definitions.mdwn
index 48e3afe..6797a2b 100644
--- a/CategoricalSyllogism/Definitions.mdwn
+++ b/CategoricalSyllogism/Definitions.mdwn
@@ -63,20 +63,12 @@ ambiguity as shown in the table below.
 | `.E.`    | <code>A .&#124;. B</code> | No B are A, A and B are non-empty |
 [Universal relations and connectives]
 
-This allows a clear formulation of deductions from universal to
-particular sentences, which are possible for the "dotted" variants:
-
-1. `A. implies I`: `A <. B => A <> B`
-2. `.A* implies I`: `B .> A => B <> A`
-3. `E. implies O`: `A |. B => A |<> B`
-4. `.E implies O*`: `B .| A => B <>| A`
-5. `.E. implies O and O*`: `A .|. B => A |<> B`, and `A .|. B => A <>| B`
-
-Such deductions from universal to particular are not possible for the
-"undotted" `A`, `A*` and `E` relations.
+These variants allow a clear formulation of the conversions from
+universal to particular sentences, which are valid for the "dotted"
+but _not valid_ for the "undotted" `A`, `A*` and `E` relations.
 
 ## References
 
-[1]: Paul Halmos and Steven Givant. Logic as Algebra. The Dolciani
+[1]: Paul Halmos and Steven Givant. *Logic as Algebra*. The Dolciani
      Mathematical Expositions Number 21, the Mathematical Association
      of America, 1998.
diff --git a/CategoricalSyllogism/SinglePremise.mdwn b/CategoricalSyllogism/SinglePremise.mdwn
new file mode 100644
index 0000000..2b7d11e
--- /dev/null
+++ b/CategoricalSyllogism/SinglePremise.mdwn
@@ -0,0 +1,30 @@
+# Deduction from single premise
+
+## From particular premise
+
+1. A <> B => There are B.
+2. B <> A => There are B.
+3. A |> B => There are B.
+4. B <| A => There are B.
+
+## To universal sentence
+
+1. There are no B. => A < B
+2. There are no B. => B > A
+3. There are no B. => A | B
+4. There are no B. => B | A
+
+## From universal premise
+
+1. A <. B => There are B.
+2. B .> A => There are B.
+3. A |. B => There are B.
+4. B .| A => There are B.
+
+Such deductions from a single universal premise are _not_ valid for
+the "undotted" `A`, `A*` and `E` relations.
+
+## References
+
+[1]: Willard van Orman Quine. *Methods of Logic*. Second Edition
+     Revised 1962, Reprinted (with corrections) 1966.

diff --git a/CategoricalSyllogism/SyllogismMatrices.mdwn b/CategoricalSyllogism/SyllogismMatrices.mdwn
index 1dada6c..d082884 100644
--- a/CategoricalSyllogism/SyllogismMatrices.mdwn
+++ b/CategoricalSyllogism/SyllogismMatrices.mdwn
@@ -10,7 +10,7 @@ indicated below for the syllogisms of figure 1.
 4. `A |  B, B <> C => A |> C` is represented as: `E I => O`
 5. `A <> B, B |  C => A <| C` is represented as: `I E => O*`
 6. `A <. B, B .| C => A <| C` is represented as: `A. .E => O*`
-   (Assuming middle term non-empty.)
+   (middle term non-empty)
 
 The reduction is non-commutative.
 

diff --git a/CategoricalSyllogism/SyllogismMatrices.mdwn b/CategoricalSyllogism/SyllogismMatrices.mdwn
index 63f0726..1dada6c 100644
--- a/CategoricalSyllogism/SyllogismMatrices.mdwn
+++ b/CategoricalSyllogism/SyllogismMatrices.mdwn
@@ -1,10 +1,38 @@
 # Matrices of valid syllogisms
 
+The form of categorical syllogisms can be represented as a reduction
+on the space of the syllogistic relations `(A*, A, E, I, O, O*)`, as
+indicated below for the syllogisms of figure 1.
+
+1. `A <  B, B <  C => A <  C` is represented as: `A A => A`
+2. `A <  B, B <> C => A <> C` is represented as: `A I => I`
+3. `A |  B, B <  C => A |  C` is represented as: `E A => E`
+4. `A |  B, B <> C => A |> C` is represented as: `E I => O`
+5. `A <> B, B |  C => A <| C` is represented as: `I E => O*`
+6. `A <. B, B .| C => A <| C` is represented as: `A. .E => O*`
+   (Assuming middle term non-empty.)
+
+The reduction is non-commutative.
+
+A conjugation operation on reductions can be defined as follows:
+
+1. (X Y)* = Y* X*
+2. X** = X
+3. (X => Y)* = (X* => Y*)
+
+Application of the `*`-operation transforms valid syllogisms into
+valid ones. For example `(E I => O)*` yields `I E => O*`.
+
 ## Statement of matrices
 
+Arranging reductions `X Y => Z` into matrices with `X` on the left
+(labeling the row), `Y` on the top (labeling the column), and the
+result `Z` in the cell of the `X`-row and the `Y`-column yields the
+matrices shown below.
+
 |     |  A  |  E  |  I  |  O  |
 | :-: | :-: | :-: | :-: | :-: |
-|  A  |  A  |._O*_|  I  |     |
+|  A  |  A  | _O*_|  I  |     |
 |  E  |  E  |     |  O  |     |
 |  I  |     |  O* |     |     |
 |  O  |     |     |     |     |
@@ -20,8 +48,8 @@
 
 |     |  A* |  E  |  I  |  O* |
 | :-: | :-: | :-: | :-: | :-: |
-|  A  |._I_ |._O*_|  I  |  O* |
-|  E  |._O_ |     |  O  |     |
+|  A  | _I_ | _O*_|  I  |  O* |
+|  E  | _O_ |     |  O  |     |
 |  I  |  I  |  O* |     |     |
 |  O  |  O  |     |     |     |
 [Matrix for figure 3]
@@ -29,27 +57,29 @@
 |     |  A* |  E  |  I  |  O* |
 | :-: | :-: | :-: | :-: | :-: |
 |  A* |  A* |  E  |     |     |
-|  E  |._O_ |     |  O  |     |
+|  E  | _O_ |     |  O  |     |
 |  I  |  I  |  O* |     |     |
 |  O* |     |     |     |     |
 [Matrix for figure 4]
 
-## Definition of matrix operations
+We display a separate matrix for each syllogistic figure.
 
-We can view `*` as a conjugation operation that transforms a relation
-`A` to its converse (or conjugate) relation `A*`. Double application
-yields the identity operation, `A** = A`.
+Reductions that require the middle term to be non-empty are included
+in the above matrices, indicated by the resulting relation symbol in
+_italics_. In cases where a non-emptiness assumption cannot be made,
+such cells would be empty.
+
+## Definition of matrix operations
 
-The conjugate matrix is obtained by applying the `*` operation
+The conjugate matrix is obtained by applying the `*`-operation
 individually to each matrix element (including the table headers).
 
-The transpose matrix is obtained by reflecting it over its main
-diagonal, meaning by exchanging rows and columns (including the table
-headers).
+The transpose matrix is obtained by exchanging rows and columns
+(including the table headers).
 
 The adjoint matrix is obtained by taking the conjugate transpose.
 
-A matrix is self-adjoint (Hermitian) when it equals to its adjoint.
+A matrix is self-adjoint (Hermitian) when it equals its adjoint.
 
 ## Properties of syllogism matrices
 

diff --git a/CategoricalSyllogism/SyllogismMatrices.mdwn b/CategoricalSyllogism/SyllogismMatrices.mdwn
index eb12b80..63f0726 100644
--- a/CategoricalSyllogism/SyllogismMatrices.mdwn
+++ b/CategoricalSyllogism/SyllogismMatrices.mdwn
@@ -1,9 +1,57 @@
 # Matrices of valid syllogisms
 
+## Statement of matrices
+
 |     |  A  |  E  |  I  |  O  |
 | :-: | :-: | :-: | :-: | :-: |
 |  A  |  A  |._O*_|  I  |     |
 |  E  |  E  |     |  O  |     |
 |  I  |     |  O* |     |     |
 |  O  |     |     |     |     |
-[Syllogism matrix for figure 1]
+[Matrix for figure 1]
+
+|     |  A  |  E  |  I  |  O  |
+| :-: | :-: | :-: | :-: | :-: |
+|  A* |     |  E  |     |  O  |
+|  E  |  E  |     |  O  |     |
+|  I  |     |  O* |     |     |
+|  O* |  O* |     |     |     |
+[Matrix for figure 2]
+
+|     |  A* |  E  |  I  |  O* |
+| :-: | :-: | :-: | :-: | :-: |
+|  A  |._I_ |._O*_|  I  |  O* |
+|  E  |._O_ |     |  O  |     |
+|  I  |  I  |  O* |     |     |
+|  O  |  O  |     |     |     |
+[Matrix for figure 3]
+
+|     |  A* |  E  |  I  |  O* |
+| :-: | :-: | :-: | :-: | :-: |
+|  A* |  A* |  E  |     |     |
+|  E  |._O_ |     |  O  |     |
+|  I  |  I  |  O* |     |     |
+|  O* |     |     |     |     |
+[Matrix for figure 4]
+
+## Definition of matrix operations
+
+We can view `*` as a conjugation operation that transforms a relation
+`A` to its converse (or conjugate) relation `A*`. Double application
+yields the identity operation, `A** = A`.
+
+The conjugate matrix is obtained by applying the `*` operation
+individually to each matrix element (including the table headers).
+
+The transpose matrix is obtained by reflecting it over its main
+diagonal, meaning by exchanging rows and columns (including the table
+headers).
+
+The adjoint matrix is obtained by taking the conjugate transpose.
+
+A matrix is self-adjoint (Hermitian) when it equals to its adjoint.
+
+## Properties of syllogism matrices
+
+* The matrices for figure 1 and figure 4 are adjoint to each other.
+* The matrix for figure 2 is self-adjoint. Same for figure 3.

diff --git a/CategoricalSyllogism/SyllogismMatrices.mdwn b/CategoricalSyllogism/SyllogismMatrices.mdwn
index 607c4b5..eb12b80 100644
--- a/CategoricalSyllogism/SyllogismMatrices.mdwn
+++ b/CategoricalSyllogism/SyllogismMatrices.mdwn
@@ -1,8 +1,8 @@
 # Matrices of valid syllogisms
 
 |     |  A  |  E  |  I  |  O  |
-| --- | --- | --- | --- | --- |
-|  A  |  A  |. O* |  I  |     |
+| :-: | :-: | :-: | :-: | :-: |
+|  A  |  A  |._O*_|  I  |     |
 |  E  |  E  |     |  O  |     |
 |  I  |     |  O* |     |     |
 |  O  |     |     |     |     |

diff --git a/CategoricalSyllogism.mdwn b/CategoricalSyllogism.mdwn
index 49f9262..6edf702 100644
--- a/CategoricalSyllogism.mdwn
+++ b/CategoricalSyllogism.mdwn
@@ -1,7 +1,8 @@
 # Categorical Syllogism
 
-* [[!traillink  Definitions text="Definitions"]]
+* [[!traillink  Definitions text="Notation and definitions"]]
 * [[!traillink  Conversion text="Conversion of sentences"]]
+* [[!traillink  SyllogismMatrices text="Matrices of valid syllogisms"]]
 
 ## References
 

diff --git a/CategoricalSyllogism/SyllogismMatrices.mdwn b/CategoricalSyllogism/SyllogismMatrices.mdwn
new file mode 100644
index 0000000..607c4b5
--- /dev/null
+++ b/CategoricalSyllogism/SyllogismMatrices.mdwn
@@ -0,0 +1,9 @@
+# Matrices of valid syllogisms
+
+|     |  A  |  E  |  I  |  O  |
+| --- | --- | --- | --- | --- |
+|  A  |  A  |. O* |  I  |     |
+|  E  |  E  |     |  O  |     |
+|  I  |     |  O* |     |     |
+|  O  |     |     |     |     |
+[Syllogism matrix for figure 1]

diff --git a/CategoricalSyllogism.mdwn b/CategoricalSyllogism.mdwn
index de76dac..49f9262 100644
--- a/CategoricalSyllogism.mdwn
+++ b/CategoricalSyllogism.mdwn
@@ -5,6 +5,6 @@
 
 ## References
 
-[1]: Aristotle, Analytica Priora
+[1]: Aristotle, *Analytica Priora*.
 [2]: https://en.wikipedia.org/wiki/Prior_Analytics "Wikipedia, Prior Analytics"
 [3]: https://en.wikipedia.org/wiki/Syllogism "Wikipedia, Syllogism"

diff --git a/CategoricalSyllogism/Conversion.mdwn b/CategoricalSyllogism/Conversion.mdwn
index acb09c3..0ce735c 100644
--- a/CategoricalSyllogism/Conversion.mdwn
+++ b/CategoricalSyllogism/Conversion.mdwn
@@ -1,9 +1,24 @@
 # Conversion of sentences
 
-1. A | B = B | A
-2. A <. B => A <> B
+## Identities
+
+1. A < B = B > A
+2. A | B = B | A
 3. A <> B = B <> A
-4. A |<> B != B |<> A
+4. A |<> B = B <>| A
+
+Likewise for the "dotted" variants:
+
+1. A <. B = B .> A
+2. A |. B = B .| A
+3. A .|. B = B .|. A
+
+## Implications
+
+1. A <. B => A <> B
+2. A |. B => A |<> B
+
+Such implications are valid for the "dotted" variants, but _not_ for the "undotted" ones.
 
 ## References
 

diff --git a/CategoricalSyllogism/Definitions.mdwn b/CategoricalSyllogism/Definitions.mdwn
index 341785b..48e3afe 100644
--- a/CategoricalSyllogism/Definitions.mdwn
+++ b/CategoricalSyllogism/Definitions.mdwn
@@ -64,7 +64,7 @@ ambiguity as shown in the table below.
 [Universal relations and connectives]
 
 This allows a clear formulation of deductions from universal to
-particular sentences, which are possible for the `.` variants:
+particular sentences, which are possible for the "dotted" variants:
 
 1. `A. implies I`: `A <. B => A <> B`
 2. `.A* implies I`: `B .> A => B <> A`

diff --git a/CategoricalSyllogism/Definitions.mdwn b/CategoricalSyllogism/Definitions.mdwn
index d2c22d3..341785b 100644
--- a/CategoricalSyllogism/Definitions.mdwn
+++ b/CategoricalSyllogism/Definitions.mdwn
@@ -64,7 +64,7 @@ ambiguity as shown in the table below.
 [Universal relations and connectives]
 
 This allows a clear formulation of deductions from universal to
-particular sentences:
+particular sentences, which are possible for the `.` variants:
 
 1. `A. implies I`: `A <. B => A <> B`
 2. `.A* implies I`: `B .> A => B <> A`
@@ -72,6 +72,9 @@ particular sentences:
 4. `.E implies O*`: `B .| A => B <>| A`
 5. `.E. implies O and O*`: `A .|. B => A |<> B`, and `A .|. B => A <>| B`
 
+Such deductions from universal to particular are not possible for the
+"undotted" `A`, `A*` and `E` relations.
+
 ## References
 
 [1]: Paul Halmos and Steven Givant. Logic as Algebra. The Dolciani

diff --git a/CategoricalSyllogism/Definitions.mdwn b/CategoricalSyllogism/Definitions.mdwn
index 702d027..d2c22d3 100644
--- a/CategoricalSyllogism/Definitions.mdwn
+++ b/CategoricalSyllogism/Definitions.mdwn
@@ -51,16 +51,16 @@ A": The Aristotle interpretation implies either of A and B to be
 non-empty, the modern one allows either to be empty. We resolve this
 ambiguity as shown in the table below.
 
-| Relation | Connective                | English Sentence               |
-| -------- | ------------------------- | ------------------------------ |
-| `A`      | `A < B`                   | All B are A (B may be empty)   |
-| `A.`     | `A <. B`                  | All B are A, B is non-empty    |
-| `A*`     | `B > A`                   | All B are A (B may be empty)   |
-| `.A*`    | `B .> A`                  | All B are A, B is non-empty    |
-| `E`      | <code>A &#124; B</code>   | No B are A (A, B may be empty) |
-| `E.`     | <code>A &#124;. B</code>  | No B are A, B is non-empty     |
-| `.E`     | <code>A .&#124; B</code>  | No B are A, A is non-empty     |
-| `.E.`    | <code>A .&#124;. B</code> | No B are A; A, B are non-empty |
+| Relation | Connective                | English Sentence                  |
+| -------- | ------------------------- | --------------------------------- |
+| `A`      | `A < B`                   | All B are A (B may be empty)      |
+| `A.`     | `A <. B`                  | All B are A, B is non-empty       |
+| `A*`     | `B > A`                   | All B are A (B may be empty)      |
+| `.A*`    | `B .> A`                  | All B are A, B is non-empty       |
+| `E`      | <code>A &#124; B</code>   | No B are A (A, B may be empty)    |
+| `E.`     | <code>A &#124;. B</code>  | No B are A, B is non-empty        |
+| `.E`     | <code>A .&#124; B</code>  | No B are A, A is non-empty        |
+| `.E.`    | <code>A .&#124;. B</code> | No B are A, A and B are non-empty |
 [Universal relations and connectives]
 
 This allows a clear formulation of deductions from universal to
@@ -70,7 +70,7 @@ particular sentences:
 2. `.A* implies I`: `B .> A => B <> A`
 3. `E. implies O`: `A |. B => A |<> B`
 4. `.E implies O*`: `B .| A => B <>| A`
-5. `.E. implies O and O*`: `A .|. B => A |<> B` and `A .|. B => A <>| B`
+5. `.E. implies O and O*`: `A .|. B => A |<> B`, and `A .|. B => A <>| B`
 
 ## References
 

diff --git a/CategoricalSyllogism/Definitions.mdwn b/CategoricalSyllogism/Definitions.mdwn
index 101b3a2..702d027 100644
--- a/CategoricalSyllogism/Definitions.mdwn
+++ b/CategoricalSyllogism/Definitions.mdwn
@@ -2,11 +2,11 @@
 
 ## Syllogistic relations and connectives
 
-| Relation | Connective | English Sentence |
-| -------- | ---------- | ---------------- |
-| A        | `A < B`      | All B are A      |
-| E        | <code>A &#124; B</code> | No B are A       |
-| I        | `A <> B`     | Some B are A     |
+| Relation | Connective                | English Sentence |
+| -------- | ------------------------- | ---------------- |
+| A        | `A < B`                   | All B are A      |
+| E        | <code>A &#124; B</code>   | No B are A       |
+| I        | `A <> B`                  | Some B are A     |
 | O        | <code>A &#124;<> B</code> | Some B are not A |
 [Syllogistic relations and connectives]
 
@@ -20,15 +20,18 @@ The syllogistic connectives are chosen so that:
   _distributed_, whereas a term facing a pointed side is
   _undistributed_. That means, the right side of `<`, both sides of
   `|`, and the left side of `|<>` are distributed.
-- Have the predicate on the left and the subject on the right. This reflects the choice made by Aristotle, modern use that applies the predicate to the subject as in `A(B)`, and has a technical advantage in the use of the chain rule.
+- Have the predicate on the left and the subject on the right. This
+  reflects the choice made by Aristotle, modern use that applies the
+  predicate to the subject as in `A(B)`, and has a technical advantage
+  in the use of the chain rule.
 
 ## Converse syllogistic relations and connectives
 
-| Code | Connective | English Sentence |
-| ---- | ---------- | ---------------- |
-| `A*`   | `B > A`      | All B are A      |
-| `E*`   | <code>B &#124; A</code> | No B are A       |
-| `I*`   | `B <> A`     | Some B are A     |
+| Code   | Connective                | English Sentence |
+| ------ | ------------------------- | ---------------- |
+| `A*`   | `B > A`                   | All B are A      |
+| `E*`   | <code>B &#124; A</code>   | No B are A       |
+| `I*`   | `B <> A`                  | Some B are A     |
 | `O*`   | <code>B <>&#124; A</code> | Some B are not A |
 [Converse relations and connectives]
 
@@ -36,8 +39,38 @@ The choice of the same connective for relations `E` and `E*` is
 possible because `E` is _symmetric_. Likewise for `I` and `I*`. That
 is, they obey the following identities:
 
-1. `E* = E`, or `B | A = A | B`
-2. `I* = I`, or `B <> A = A <> B`
+1. `E* = E`: `B | A = A | B`
+2. `I* = I`: `B <> A = A <> B`
+
+# Interpretation of universal syllogistic relations
+
+There are two interpretations of the universal sentence "All B are A":
+The one by Aristotle implies B to be non-empty, whereas the modern one
+allows B to be empty. Likewise for the universal sentence "No B are
+A": The Aristotle interpretation implies either of A and B to be
+non-empty, the modern one allows either to be empty. We resolve this
+ambiguity as shown in the table below.
+
+| Relation | Connective                | English Sentence               |
+| -------- | ------------------------- | ------------------------------ |
+| `A`      | `A < B`                   | All B are A (B may be empty)   |
+| `A.`     | `A <. B`                  | All B are A, B is non-empty    |
+| `A*`     | `B > A`                   | All B are A (B may be empty)   |
+| `.A*`    | `B .> A`                  | All B are A, B is non-empty    |
+| `E`      | <code>A &#124; B</code>   | No B are A (A, B may be empty) |
+| `E.`     | <code>A &#124;. B</code>  | No B are A, B is non-empty     |
+| `.E`     | <code>A .&#124; B</code>  | No B are A, A is non-empty     |
+| `.E.`    | <code>A .&#124;. B</code> | No B are A; A, B are non-empty |
+[Universal relations and connectives]
+
+This allows a clear formulation of deductions from universal to
+particular sentences:
+
+1. `A. implies I`: `A <. B => A <> B`
+2. `.A* implies I`: `B .> A => B <> A`
+3. `E. implies O`: `A |. B => A |<> B`
+4. `.E implies O*`: `B .| A => B <>| A`
+5. `.E. implies O and O*`: `A .|. B => A |<> B` and `A .|. B => A <>| B`
 
 ## References
 

diff --git a/CategoricalSyllogism/Definitions.mdwn b/CategoricalSyllogism/Definitions.mdwn
index 7c7d184..101b3a2 100644
--- a/CategoricalSyllogism/Definitions.mdwn
+++ b/CategoricalSyllogism/Definitions.mdwn
@@ -8,7 +8,7 @@
 | E        | <code>A &#124; B</code> | No B are A       |
 | I        | `A <> B`     | Some B are A     |
 | O        | <code>A &#124;<> B</code> | Some B are not A |
-[Definition of syllogistic relations and connectives]
+[Syllogistic relations and connectives]
 
 The syllogistic connectives are chosen so that:
 
@@ -20,7 +20,7 @@ The syllogistic connectives are chosen so that:
   _distributed_, whereas a term facing a pointed side is
   _undistributed_. That means, the right side of `<`, both sides of
   `|`, and the left side of `|<>` are distributed.
-- Put the predicate to the left and the subject to the right.
+- Have the predicate on the left and the subject on the right. This reflects the choice made by Aristotle, modern use that applies the predicate to the subject as in `A(B)`, and has a technical advantage in the use of the chain rule.
 
 ## Converse syllogistic relations and connectives
 
@@ -30,7 +30,7 @@ The syllogistic connectives are chosen so that:
 | `E*`   | <code>B &#124; A</code> | No B are A       |
 | `I*`   | `B <> A`     | Some B are A     |
 | `O*`   | <code>B <>&#124; A</code> | Some B are not A |
-[Definition of converse relations and connectives]
+[Converse relations and connectives]
 
 The choice of the same connective for relations `E` and `E*` is
 possible because `E` is _symmetric_. Likewise for `I` and `I*`. That

diff --git a/index.mdwn b/index.mdwn
index 9c87455..0b2e349 100644
--- a/index.mdwn
+++ b/index.mdwn
@@ -2,4 +2,6 @@ This wiki is under construction. Until further notice I am using it for explorin
 
 Try the Alice & Bob [[GitTutorial]].
 
+An algebraic treatment of [[CategoricalSyllogism]] is in preparation.
+
 All wikis are supposed to have a [[SandBox]], so this one does too.

diff --git a/CategoricalSyllogism/Definitions.mdwn b/CategoricalSyllogism/Definitions.mdwn
index 030c56a..7c7d184 100644
--- a/CategoricalSyllogism/Definitions.mdwn
+++ b/CategoricalSyllogism/Definitions.mdwn
@@ -26,10 +26,10 @@ The syllogistic connectives are chosen so that:
 
 | Code | Connective | English Sentence |
 | ---- | ---------- | ---------------- |
-| A*   | B > A      | All B are A      |
-| E*   | <code>A &#124; B</code> | No B are A       |
-| I*   | B <> A     | Some B are A     |
-| O*   | <code>B <>&#124; A</code>    | Some B are not A |
+| `A*`   | `B > A`      | All B are A      |
+| `E*`   | <code>B &#124; A</code> | No B are A       |
+| `I*`   | `B <> A`     | Some B are A     |
+| `O*`   | <code>B <>&#124; A</code> | Some B are not A |
 [Definition of converse relations and connectives]
 
 The choice of the same connective for relations `E` and `E*` is

diff --git a/CategoricalSyllogism/Definitions.mdwn b/CategoricalSyllogism/Definitions.mdwn
index 2261c88..030c56a 100644
--- a/CategoricalSyllogism/Definitions.mdwn
+++ b/CategoricalSyllogism/Definitions.mdwn
@@ -4,10 +4,10 @@
 
 | Relation | Connective | English Sentence |
 | -------- | ---------- | ---------------- |
-| A        | A < B      | All B are A      |
-| E        | A | B      | No B are A       |
-| I        | A <> B     | Some B are A     |
-| O        | A |<> B    | Some B are not A |
+| A        | `A < B`      | All B are A      |
+| E        | <code>A &#124; B</code> | No B are A       |
+| I        | `A <> B`     | Some B are A     |
+| O        | <code>A &#124;<> B</code> | Some B are not A |
 [Definition of syllogistic relations and connectives]
 
 The syllogistic connectives are chosen so that:
@@ -27,9 +27,9 @@ The syllogistic connectives are chosen so that:
 | Code | Connective | English Sentence |
 | ---- | ---------- | ---------------- |
 | A*   | B > A      | All B are A      |
-| E*   | B | A      | No B are A       |
+| E*   | <code>A &#124; B</code> | No B are A       |
 | I*   | B <> A     | Some B are A     |
-| O*   | B <>| A    | Some B are not A |
+| O*   | <code>B <>&#124; A</code>    | Some B are not A |
 [Definition of converse relations and connectives]
 
 The choice of the same connective for relations `E` and `E*` is

diff --git a/CategoricalSyllogism.mdwn b/CategoricalSyllogism.mdwn
new file mode 100644
index 0000000..de76dac
--- /dev/null
+++ b/CategoricalSyllogism.mdwn
@@ -0,0 +1,10 @@
+# Categorical Syllogism
+
+* [[!traillink  Definitions text="Definitions"]]
+* [[!traillink  Conversion text="Conversion of sentences"]]
+
+## References
+
+[1]: Aristotle, Analytica Priora
+[2]: https://en.wikipedia.org/wiki/Prior_Analytics "Wikipedia, Prior Analytics"
+[3]: https://en.wikipedia.org/wiki/Syllogism "Wikipedia, Syllogism"
diff --git a/CategoricalSyllogism/Conversion.mdwn b/CategoricalSyllogism/Conversion.mdwn
new file mode 100644
index 0000000..acb09c3
--- /dev/null
+++ b/CategoricalSyllogism/Conversion.mdwn
@@ -0,0 +1,10 @@
+# Conversion of sentences
+
+1. A | B = B | A
+2. A <. B => A <> B
+3. A <> B = B <> A
+4. A |<> B != B |<> A
+
+## References
+
+[1]: Aristotle, Analytica Priora, Book 1, Chapter 2
diff --git a/CategoricalSyllogism/Definitions.mdwn b/CategoricalSyllogism/Definitions.mdwn
new file mode 100644
index 0000000..2261c88
--- /dev/null
+++ b/CategoricalSyllogism/Definitions.mdwn
@@ -0,0 +1,46 @@
+# Definitions
+
+## Syllogistic relations and connectives
+
+| Relation | Connective | English Sentence |
+| -------- | ---------- | ---------------- |
+| A        | A < B      | All B are A      |
+| E        | A | B      | No B are A       |
+| I        | A <> B     | Some B are A     |
+| O        | A |<> B    | Some B are not A |
+[Definition of syllogistic relations and connectives]
+
+The syllogistic connectives are chosen so that:
+
+- Connective `<` within formula `A < B` resembles the inclusion arrow,
+  meaning that `B` is _included_ in `A`. In case of sets `A` and `B`
+  it indicates that `B` is a subset of `A`.
+- A vertical bar `|` indicates a negative relation.
+- A term facing an open side of a syllogistic connective is
+  _distributed_, whereas a term facing a pointed side is
+  _undistributed_. That means, the right side of `<`, both sides of
+  `|`, and the left side of `|<>` are distributed.
+- Put the predicate to the left and the subject to the right.
+
+## Converse syllogistic relations and connectives
+
+| Code | Connective | English Sentence |
+| ---- | ---------- | ---------------- |
+| A*   | B > A      | All B are A      |
+| E*   | B | A      | No B are A       |
+| I*   | B <> A     | Some B are A     |
+| O*   | B <>| A    | Some B are not A |
+[Definition of converse relations and connectives]
+
+The choice of the same connective for relations `E` and `E*` is
+possible because `E` is _symmetric_. Likewise for `I` and `I*`. That
+is, they obey the following identities:
+
+1. `E* = E`, or `B | A = A | B`
+2. `I* = I`, or `B <> A = A <> B`
+
+## References
+
+[1]: Paul Halmos and Steven Givant. Logic as Algebra. The Dolciani
+     Mathematical Expositions Number 21, the Mathematical Association
+     of America, 1998.

diff --git a/sidebar.mdwn b/sidebar.mdwn
index 404f1a5..7b05f7a 100644
--- a/sidebar.mdwn
+++ b/sidebar.mdwn
@@ -1,3 +1,3 @@
 [Homepage](http://tph.tuwien.ac.at/~ertl/)
 [[Wiki|index]]
-[[!cantarius index desc="Blog"]]
+[Blog](http://cantarius.branchable.com/)

diff --git a/sidebar.mdwn b/sidebar.mdwn
index 74a9e0a..404f1a5 100644
--- a/sidebar.mdwn
+++ b/sidebar.mdwn
@@ -1,3 +1,3 @@
 [Homepage](http://tph.tuwien.ac.at/~ertl/)
 [[Wiki|index]]
-[[!cantarius desc="Blog"]]
+[[!cantarius index desc="Blog"]]

diff --git a/sidebar.mdwn b/sidebar.mdwn
index 8dc53e7..74a9e0a 100644
--- a/sidebar.mdwn
+++ b/sidebar.mdwn
@@ -1,3 +1,3 @@
 [Homepage](http://tph.tuwien.ac.at/~ertl/)
-[Wiki](http://martinertl.branchable.com/)
+[[Wiki|index]]
 [[!cantarius desc="Blog"]]

diff --git a/sidebar.mdwn b/sidebar.mdwn
index 962ebc6..8dc53e7 100644
--- a/sidebar.mdwn
+++ b/sidebar.mdwn
@@ -1 +1,3 @@
-* [[!cantarius desc="Cantarius blog"]]
+[Homepage](http://tph.tuwien.ac.at/~ertl/)
+[Wiki](http://martinertl.branchable.com/)
+[[!cantarius desc="Blog"]]

diff --git a/sidebar.mdwn b/sidebar.mdwn
new file mode 100644
index 0000000..962ebc6
--- /dev/null
+++ b/sidebar.mdwn
@@ -0,0 +1 @@
+* [[!cantarius desc="Cantarius blog"]]

diff --git a/shortcuts.mdwn b/shortcuts.mdwn
new file mode 100644
index 0000000..4b79175
--- /dev/null
+++ b/shortcuts.mdwn
@@ -0,0 +1,87 @@
+[[!if test="enabled(shortcut)"
+     then="This wiki has shortcuts **enabled**."
+     else="This wiki has shortcuts **disabled**."]]
+
+Some examples of using shortcuts include:
+
+	\[[!google foo]]
+	\[[!wikipedia War_of_1812]]
+	\[[!debbug 12345]]
+	Check the \[[!google ikiwiki desc="google search for %s"]].
+
+This page controls what shortcut links the wiki supports.
+
+* [[!shortcut name=cantarius url="http://cantarius.branchable.com/%S/"]]
+* [[!shortcut name=google url="https://encrypted.google.com/search?q=%s"]]
+* [[!shortcut name=archive url="http://web.archive.org/*/%S"]]
+* [[!shortcut name=gmap url="https://maps.google.com/maps?q=%s"]]
+* [[!shortcut name=gmsg url="https://groups.google.com/groups?selm=%s"]]
+* [[!shortcut name=wikipedia url="https://en.wikipedia.org/wiki/%W"]]
+* [[!shortcut name=wikitravel url="https://wikitravel.org/en/%s"]]
+* [[!shortcut name=wiktionary url="https://en.wiktionary.org/wiki/%s"]]
+* [[!shortcut name=debbug url="http://bugs.debian.org/%S" desc="Debian bug #%s"]]
+* [[!shortcut name=deblist url="https://lists.debian.org/debian-%s" desc="debian-%s@lists.debian.org"]]
+* [[!shortcut name=debpkg url="http://packages.debian.org/%s"]]
+* [[!shortcut name=debpkgsid url="http://packages.debian.org/sid/%s"]]
+* [[!shortcut name=debpts url="http://packages.qa.debian.org/%s"]]
+* [[!shortcut name=debmsg url="https://lists.debian.org/msgid-search/%s"]]
+* [[!shortcut name=debrt url="https://rt.debian.org/Ticket/Display.html?id=%s"]]
+* [[!shortcut name=debss url="http://snapshot.debian.org/package/%s/"]]
+  * Usage: `\[[!debss package]]` or `\[[!debss package/version]]`.  See <http://snapshot.debian.org/> for details.
+* [[!shortcut name=debwiki url="https://wiki.debian.org/%S"]]
+* [[!shortcut name=fdobug url="https://bugs.freedesktop.org/show_bug.cgi?id=%s" desc="freedesktop.org bug #%s"]]
+* [[!shortcut name=fdolist url="http://lists.freedesktop.org/mailman/listinfo/%s" desc="%s@lists.freedesktop.org"]]
+* [[!shortcut name=gnomebug url="https://bugzilla.gnome.org/show_bug.cgi?id=%s" desc="GNOME bug #%s"]]
+* [[!shortcut name=linuxbug url="https://bugzilla.kernel.org/show_bug.cgi?id=%s" desc="Linux bug #%s"]]
+* [[!shortcut name=mozbug url="https://bugzilla.mozilla.org/show_bug.cgi?id=%s" desc="Mozilla bug #%s"]]
+* [[!shortcut name=gnulist url="https://lists.gnu.org/mailman/listinfo/%s" desc="%s@gnu.org"]]
+* [[!shortcut name=marcmsg url="http://marc.info/?i=%s"]]
+* [[!shortcut name=marclist url="http://marc.info/?l=%s"]]
+* [[!shortcut name=gmane url="http://dir.gmane.org/gmane.%s" desc="gmane.%s"]]
+* [[!shortcut name=gmanemsg url="http://mid.gmane.org/%s"]]
+* [[!shortcut name=cpan url="http://search.cpan.org/search?mode=dist&query=%s"]]
+* [[!shortcut name=ctan url="http://tug.ctan.org/cgi-bin/ctanPackageInformation.py?id=%s"]]
+* [[!shortcut name=hoogle url="http://haskell.org/hoogle/?q=%s"]]
+* [[!shortcut name=iki url="http://ikiwiki.info/%S/"]]
+* [[!shortcut name=ljuser url="http://%s.livejournal.com/"]]
+* [[!shortcut name=rfc url="https://www.ietf.org/rfc/rfc%s.txt" desc="RFC %s"]]
+* [[!shortcut name=c2 url="http://c2.com/cgi/wiki?%s"]]
+* [[!shortcut name=meatballwiki url="http://www.usemod.com/cgi-bin/mb.pl?%s"]]
+* [[!shortcut name=emacswiki url="http://www.emacswiki.org/cgi-bin/wiki/%s"]]
+* [[!shortcut name=haskellwiki url="http://haskell.org/haskellwiki/%s"]]
+* [[!shortcut name=dict url="http://www.dict.org/bin/Dict?Form=Dict1&Strategy=*&Database=*&Query=%s"]]
+* [[!shortcut name=imdb url="http://imdb.com/find?q=%s"]]
+* [[!shortcut name=gpg url="http://pgpkeys.mit.edu:11371/pks/lookup?op=vindex&exact=on&search=0x%s"]]
+* [[!shortcut name=perldoc url="http://perldoc.perl.org/search.html?q=%s"]]
+* [[!shortcut name=whois url="http://reports.internic.net/cgi/whois?whois_nic=%s&type=domain"]]
+* [[!shortcut name=cve url="https://cve.mitre.org/cgi-bin/cvename.cgi?name=%s"]]
+* [[!shortcut name=flickr url="https://secure.flickr.com/photos/%s"]]
+* [[!shortcut name=man url="http://manpages.debian.org/%s"]]
+* [[!shortcut name=ohloh url="https://www.ohloh.net/p/%s"]]
+* [[!shortcut name=cpanrt url="https://rt.cpan.org/Ticket/Display.html?id=%s" desc="CPAN RT#%s"]]
+* [[!shortcut name=novellbug url="https://bugzilla.novell.com/show_bug.cgi?id=%s" desc="bug %s"]]
+* [[!shortcut name=ubupkg url="http://packages.ubuntu.com/%s"]]
+* [[!shortcut name=mozillazinekb url="http://kb.mozillazine.org/%s"]]
+* [[!shortcut name=freebsdwiki url="http://wiki.freebsd.org/%s"]]
+* [[!shortcut name=hackage url="http://hackage.haskell.org/package/%s"]]
+* [[!shortcut name=pkgsrc url="http://pkgsrc.se/%S"]]
+* [[!shortcut name=doi url="http://dx.doi.org/%s" desc="doi:%s"]]
+* [[!shortcut name=arxiv url="http://arxiv.org/abs/%s" desc="arXiv:%s"]]
+
+To add a new shortcut, use the `shortcut`
+[[ikiwiki/directive]]. In the url, "%s" is replaced with the
+text passed to the named shortcut, after [[!wikipedia url_encoding]]
+it, and '%S' is replaced with the raw, non-encoded text. 
+Additionally, `%W` is replaced with the text encoded just right for
+Wikipedia. The optional `desc` parameter controls the description of
+the link.
+
+Remember that the `name` you give the shortcut will become a new
+[[ikiwiki/directive]].  Avoid using a `name` that conflicts
+with an existing directive.  These directives also accept a `desc`
+parameter that will override the one provided at definition time.
+
+If you come up with a shortcut that you think others might find useful,
+consider contributing it to the [shortcuts page on the ikiwiki
+wiki](http://ikiwiki.info/shortcuts/), so that future versions of
+ikiwiki will include your shortcut in the standard underlay.

diff --git a/GitTutorialDocument.mdwn b/GitTutorialDocument.mdwn
deleted file mode 100644
index bc9cbb3..0000000
--- a/GitTutorialDocument.mdwn
+++ /dev/null
@@ -1 +0,0 @@
-[[!inline pagenames="GitTutorial/PrivateRepository GitTutorial/RemoteRepositories GitTutorial/GitServer GitTutorial/BranchingAndMerging GitTutorial/References" raw="yes"]]

diff --git a/GitTutorial/sidebar.mdwn b/GitTutorial/sidebar.mdwn
index 260cedf..3dee8ce 100644
--- a/GitTutorial/sidebar.mdwn
+++ b/GitTutorial/sidebar.mdwn
@@ -1,2 +1 @@
 * [[AllInOne]]
-* [[GitTutorialDocument]]

diff --git a/GitTutorial/sidebar.mdwn b/GitTutorial/sidebar.mdwn
index 3dee8ce..260cedf 100644
--- a/GitTutorial/sidebar.mdwn
+++ b/GitTutorial/sidebar.mdwn
@@ -1 +1,2 @@
 * [[AllInOne]]
+* [[GitTutorialDocument]]

diff --git a/GitTutorialDocument.mdwn b/GitTutorialDocument.mdwn
new file mode 100644
index 0000000..bc9cbb3
--- /dev/null
+++ b/GitTutorialDocument.mdwn
@@ -0,0 +1 @@
+[[!inline pagenames="GitTutorial/PrivateRepository GitTutorial/RemoteRepositories GitTutorial/GitServer GitTutorial/BranchingAndMerging GitTutorial/References" raw="yes"]]

diff --git a/GitTutorial/AllInOne.mdwn b/GitTutorial/AllInOne.mdwn
index 30fae1e..bc9cbb3 100644
--- a/GitTutorial/AllInOne.mdwn
+++ b/GitTutorial/AllInOne.mdwn
@@ -1 +1 @@
-[[!inline pagenames="GitTutorial/PrivateRepository GitTutorial/RemoteRepositories GitTutorial/GitServer GitTutorial/BranchingAndMerging GitTutorial/References"]]
+[[!inline pagenames="GitTutorial/PrivateRepository GitTutorial/RemoteRepositories GitTutorial/GitServer GitTutorial/BranchingAndMerging GitTutorial/References" raw="yes"]]

diff --git a/GitTutorial/AllInOne.mdwn b/GitTutorial/AllInOne.mdwn
new file mode 100644
index 0000000..30fae1e
--- /dev/null
+++ b/GitTutorial/AllInOne.mdwn
@@ -0,0 +1 @@
+[[!inline pagenames="GitTutorial/PrivateRepository GitTutorial/RemoteRepositories GitTutorial/GitServer GitTutorial/BranchingAndMerging GitTutorial/References"]]

diff --git a/GitTutorial.mdwn b/GitTutorial.mdwn
index eff51f3..430475e 100644
--- a/GitTutorial.mdwn
+++ b/GitTutorial.mdwn
@@ -5,5 +5,5 @@ date: June 18, 2015
 * [[!traillink  PrivateRepository text="Session 1: Alice starts with a private repository"]]
 * [[!traillink  RemoteRepositories text="Session 2: Bob joins Alice to work together"]]
 * [[!traillink  GitServer text="Session 3: Alice & Bob use a Git server"]]
-* [[!traillink  BrangingAndMerging text="Session 4: Alice & Bob become Git experts by branching and merging"]]
+* [[!traillink  BranchingAndMerging text="Session 4: Alice & Bob become Git experts by branching and merging"]]
 * [[!traillink  References text="Session 5: Getting help and support"]]

diff --git a/GitTutorial/BranchingAndMerging.mdwn b/GitTutorial/BranchingAndMerging.mdwn
new file mode 100644
index 0000000..3bb722d
--- /dev/null
+++ b/GitTutorial/BranchingAndMerging.mdwn
@@ -0,0 +1,144 @@
+# Session 4: Alice & Bob become Git experts by branching and merging
+
+## Alice & Bob define the branching policy
+
+Here is a branching policy for a data centre:
+
+     (L3) Temporary branches for hot fixes: '<issue>_hotfix'
+     (L2) Permanent branch for operations system: 'ops'
+     (L1) Permanent branch for test system: 'tst'
+     (L0) Permanent branch for development: 'master'
+    (L-1) Temporary branches for feature implementation: '<feature>_impl'
+
+Merging from upper to lower level is a safe action and can be done
+frequently. Merging from lower to upper level must be done with care
+and is considered a "delivery".
+
+## Alice creates the permanent branches: checkout -b, checkout, gitk, push -u
+
+Branch `master` doesn't need to be created. It is created by Git and
+always there.
+
+Create local branches (use -b flag):
+
+    git checkout -b tst                # starting from HEAD
+    git checkout -b ops <start_point>  # starting from start_point (e.g. commit)
+
+Switch between branches:
+
+    git status # always make sure to have a clean working directory!
+    git checkout <branch>
+
+Add commits to each branch, then use the graphical repository browser
+for the inspection (may sometimes be more convenient than `git log`
+and `git diff`):
+
+    gitk &
+
+Push branches to Git server (use -u flag):
+
+    git push -u <remote> <local_branch>:<remote_branch>
+    git push -u eodc tst:tst
+    git push -u eodc ops:ops
+
+## Bob gets the new remote branches: checkout -t
+
+    git fetch eodc              # update remote tracking branches
+    git branch -a               # view list of branches
+    git checkout -t eodc/tst    # use -t to set up "upstream" configuration
+    git checkout -t eodc/ops
+
+## Bob delivers work on a feature branch: checkout -b, push -u, *merge request*
+
+    git checkout master
+    git checkout -b <feature>_impl
+
+He does some work, then stages and commits it:
+
+    git add <file>...
+    git commit
+
+    git push -u eodc <feature>_impl:<feature>_impl
+
+Finally, Bob submits a merge request to Alice (talk, send an email, or
+press GitLab's *New Merge Request* button).
+
+## Alice integrates Bob's changes: merge, tag, branch -d
+
+    git fetch eodc
+    git checkout -t eodc/<feature>_impl
+
+Alice can and should inspect the changes made by Bob. She talks to him
+in case of disagreement.
+
+Alice merges feature branch into master:
+
+    git checkout master
+    git merge --no-commit <feature>_impl # Don't abuse --no-commit!
+    git status
+    git diff
+
+In case of conflicts, Alice resolves them. She also has the option to
+abort the merge. See the sections on *conflict resolution* and
+*aborting* below.
+
+If everything OK, Alice commits and tags:
+
+    git commit
+    git tag -a -m "DCR-001: Feature XYZ" DCR-001-0
+
+Alice pushes to Git server and removes obsolete feature branch:
+
+    git push eodc master
+    git branch -d <feature>_impl    # delete local branch
+    git push eodc :<feature>_impl   # delete remote branch
+
+Alice notifies Bob about integration action.
+
+## Bob verifies integration: fetch --prune
+
+    git fetch eodc           # fetch is additive, it doesn't delete branches
+    git fetch --prune eodc   # prune obsolete remote tracking branches
+    git checkout master
+    git pull
+    gitk &
+    git branch -d <feature>_impl
+
+## Alice's options for conflict resolution: checkout --ours|--theirs|-m, add
+
+When a `git merge` reports about conflicts:
+
+* Look at the diffs: `git diff` will show a three-way diff,
+  highlighting changes from both the HEAD and MERGE_HEAD versions.
+* Look at the diffs from each branch: `git log --merge -p <path>` will
+  show diffs first for the HEAD version and then the MERGE_HEAD
+  version.
+* Look at the originals: `git show :1:filename` shows the common
+  ancestor, `git show :2:filename` shows the HEAD version, and `git
+  show :3:filename` shows the MERGE_HEAD version.
+
+Alice can use the following commands in order to resolve conflicts:
+
+    git checkout --ours -- <file>
+    git checkout --theirs -- <file>
+    git checkout -m -- <file>        # gets conflicts back
+    vi <file>                        # find conflict markers and fix things
+
+    git add <file>                   # mark conflict as resolved.
+    git commit
+
+## Alice's options for aborting a failed merge: merge --abort, reset --hard, revert -m 1
+
+If things go entirely wrong, the merge can be aborted **before
+committing** by one of the following commands:
+
+    git merge --abort                # requires a newer Git version
+    git reset --hard HEAD
+
+Revert the merge after committing but **before pushing** as follows:
+
+    git reset --hard HEAD^
+
+Revert the merge after pushing as follows:
+
+    git revert -m 1 <commit>
diff --git a/GitTutorial/BrangingAndMerging.mdwn b/GitTutorial/BrangingAndMerging.mdwn
deleted file mode 100644
index 3bb722d..0000000
--- a/GitTutorial/BrangingAndMerging.mdwn
+++ /dev/null
@@ -1,144 +0,0 @@
-# Session 4: Alice & Bob become Git experts by branching and merging
-
-## Alice & Bob define the branching policy
-
-Here is a branching policy for a data centre:
-
-     (L3) Temporary branches for hot fixes: '<issue>_hotfix'
-     (L2) Permanent branch for operations system: 'ops'
-     (L1) Permanent branch for test system: 'tst'
-     (L0) Permanent branch for development: 'master'
-    (L-1) Temporary branches for feature implementation: '<feature>_impl'
-
-Merging from upper to lower level is a safe action and can be done
-frequently. Merging from lower to upper level must be done with care
-and is considered a "delivery".
-
-## Alice creates the permanent branches: checkout -b, checkout, gitk, push -u
-
-Branch `master` doesn't need to be created. It is created by Git and
-always there.
-
-Create local branches (use -b flag):
-
-    git checkout -b tst                # starting from HEAD
-    git checkout -b ops <start_point>  # starting from start_point (e.g. commit)
-
-Switch between branches:
-
-    git status # always make sure to have a clean working directory!
-    git checkout <branch>
-
-Add commits to each branch, then use the graphical repository browser
-for the inspection (may sometimes be more convenient than `git log`
-and `git diff`):
-
-    gitk &
-
-Push branches to Git server (use -u flag):
-
-    git push -u <remote> <local_branch>:<remote_branch>
-    git push -u eodc tst:tst
-    git push -u eodc ops:ops
-
-## Bob gets the new remote branches: checkout -t

(Diff truncated)

diff --git a/GitTutorial/sidebar.mdwn b/GitTutorial/sidebar.mdwn
new file mode 100644
index 0000000..3dee8ce
--- /dev/null
+++ b/GitTutorial/sidebar.mdwn
@@ -0,0 +1 @@
+* [[AllInOne]]

diff --git a/GitTutorial/PrivateRepository.mdwn b/GitTutorial/PrivateRepository.mdwn
index 5274996..b0111aa 100644
--- a/GitTutorial/PrivateRepository.mdwn
+++ b/GitTutorial/PrivateRepository.mdwn
@@ -44,7 +44,7 @@ It's just `init`, `add` and `commit`, but to get standardization of line endings
     git status
     git log
 
-Here is a procedure for automatically fixing all line endings after changing `core.autocrlf` option or `.gitattributes` file:
+Here is a procedure for automatically fixing all line endings after changing `core.autocrlf` option or [[`.gitattributes`|gitattributes]] file:
 
     git status           # check status
     git add . -u         # Save current files, so that no work is lost

diff --git a/GitTutorial/PrivateRepository/gitattributes b/GitTutorial/PrivateRepository/gitattributes
new file mode 100644
index 0000000..f4abc86
--- /dev/null
+++ b/GitTutorial/PrivateRepository/gitattributes
@@ -0,0 +1,46 @@
+# References:
+#   https://help.github.com/articles/dealing-with-line-endings/
+#   http://adaptivepatchwork.com/2012/03/01/mind-the-end-of-your-line/
+
+# Set the default behavior, in case people don't have core.autocrlf set.
+
+* text=auto
+
+# Explicitly declare text files you want to always be normalized and
+# converted to native line endings on checkout.
+
+*.md      text
+*.html    text
+*.txt     text
+
+*.c       text
+*.cc      text
+*.h       text
+*.hh      text
+*.py      text
+
+# Declare files that will always have CRLF line endings on checkout.
+
+*.sln     text eol=crlf
+
+# Denote all files that are truly binary and should not be modified.
+
+*.gz      binary
+*.tar     binary
+*.tgz     binary
+*.zip     binary
+
+*.gif     binary
+*.jpeg    binary
+*.jpg     binary
+*.nc      binary
+*.png     binary
+
+*.doc     binary
+*.docx    binary
+*.pdf     binary
+*.ppt     binary
+*.pptx    binary
+*.vsd     binary
+*.xls     binary
+*.xlsx    binary

diff --git a/GitTutorial/PrivateRepository.mdwn b/GitTutorial/PrivateRepository.mdwn
index d4f9772..5274996 100644
--- a/GitTutorial/PrivateRepository.mdwn
+++ b/GitTutorial/PrivateRepository.mdwn
@@ -32,7 +32,7 @@ Check user's global options with: `git config --global --list`
 
 It's just `init`, `add` and `commit`, but to get standardization of line endings (LF), and to exclude generated files, she does a little bit more:
 
-    cd <dir>               # for example `cci_cm_demo_src`
+    cd <dir>               # for example `cci_sm_demo_src`
     git init
     git status
     git add .gitattributes

diff --git a/index.mdwn b/index.mdwn
index 99e1010..9c87455 100644
--- a/index.mdwn
+++ b/index.mdwn
@@ -1,5 +1,5 @@
 This wiki is under construction. Until further notice I am using it for exploring Branchable and [[Ikiwiki]].
 
-Here is the Bob & Alice [[GitTutorial]].
+Try the Alice & Bob [[GitTutorial]].
 
 All wikis are supposed to have a [[SandBox]], so this one does too.

diff --git a/GitTutorial/References.mdwn b/GitTutorial/References.mdwn
index 641cb47..ad28f15 100644
--- a/GitTutorial/References.mdwn
+++ b/GitTutorial/References.mdwn
@@ -1,4 +1,4 @@
-# Session 5: How Alice and Bob find help
+# Session 5: Getting help and support
 
 * README_GIT.md in repository [`cci_cm_work_doc`](https://git.eodc.eu/cci-sm-work/cci_sm_work_doc).
 * Tutorials and cheatsheets on the Internet.

diff --git a/GitTutorial.mdwn b/GitTutorial.mdwn
index 42881cb..eff51f3 100644
--- a/GitTutorial.mdwn
+++ b/GitTutorial.mdwn
@@ -2,8 +2,8 @@ title: Git Tutorial and Demo for CCI Soil Moisture Phase 2 Project Meeting #2
 author: Martin Ertl (AWST)
 date: June 18, 2015
 
-* [[!traillink  PrivateRepository]]
-* [[!traillink  RemoteRepositories]]
-* [[!traillink  GitServer]]
-* [[!traillink  BrangingAndMerging]]
-* [[!traillink  References]]
+* [[!traillink  PrivateRepository text="Session 1: Alice starts with a private repository"]]
+* [[!traillink  RemoteRepositories text="Session 2: Bob joins Alice to work together"]]
+* [[!traillink  GitServer text="Session 3: Alice & Bob use a Git server"]]
+* [[!traillink  BrangingAndMerging text="Session 4: Alice & Bob become Git experts by branching and merging"]]
+* [[!traillink  References text="Session 5: Getting help and support"]]

diff --git a/GitTutorial.mdwn b/GitTutorial.mdwn
index 1a10aa3..42881cb 100644
--- a/GitTutorial.mdwn
+++ b/GitTutorial.mdwn
@@ -7,355 +7,3 @@ date: June 18, 2015
 * [[!traillink  GitServer]]
 * [[!traillink  BrangingAndMerging]]
 * [[!traillink  References]]
-
-# Session 1: Alice starts with a private repository
-
-Why is Alice using a version control system:
-
-* It is easy to manage a few files. But for 100 files and more, she
-  needs tool support.
-* She finds web up- and download clumsy. If the file is on the web,
-  then it is not there where she needs it for work: on her local file
-  system
-* For files used in collaboration, she wants to know who made the
-  change, when, and for what purpose.
-
-Why is Alice using Git:
-
-* Git development was initiated by Linus Torvalds, the developer of
-  the Linux kernel. That indicates quality.
-* For about two years (or more) Open Source Software (OSS) developers
-  seem to prefer Git and GitHub.
-* She works for the ESA wonderland. The ESA Thematic Exploitation
-  Platform (TEP) Reference Architecture and Standards recommend Git
-  (see OSS Best Practices).
-* She has a friend who has partners and clients who did not choose a
-  common standard. He had to learn them all: ClearCase, CVS,
-  Subversion, Git, etc.
-* She knows EODC. They `push` collaboration and `pull` standards from
-  GitLab.
-
-## Alice configures her Git client: config --global|--list
-
-Set user's global options (on Linux):
-
-    git config --global user.name "Alice from Wonderland"
-    git config --global user.email alice@wonderland.net
-    git config --global color.ui true
-    git config --global core.safecrlf warn
-    git config --global core.autocrlf input
-
-On Windows, set `core.autocrlf` to `true`.
-
-Check user's global options with: `git config --global --list`
-
-## Alice turns a directory into a Git repository: init, add, commit
-
-It's just `init`, `add` and `commit`, but to get standardization of
-line endings (LF), and to exclude generated files, she does a little
-bit more:
-
-    cd <dir>               # for example `cci_cm_demo_src`
-    git init
-    git status
-    git add .gitattributes
-    git add .gitignore
-    git add .
-    git status
-    git commit
-    git checkout HEAD -- . # remove CRLF from working directory, if any
-    git status
-    git log
-
-Here is a procedure for automatically fixing all line endings after
-changing `core.autocrlf` option or `.gitattributes` file:
-
-    git status           # check status
-    git add . -u         # Save current files, so that no work is lost
-    git commit -m "Save files before refreshing line endings."
-    git rm --cached -r . # remove every file from index (cache, staging area)
-    git reset --hard     # rewrite index to pick up all new line endings
-    git add .            # add changed files back
-    git commit -m "Normalize all line endings."
-
-## Alice edits files: status, diff, add, commit, log
-
-    vi <file>
-
-    git status
-    git diff
-    git add <file>
-    git diff --cached
-    git status
-    git commit
-    git status
-
-    git log
-    git log --oneline
-    git log --name-status
-    git log -p
-
-### Move and remove files or directories: mv, rm
-
-    git mv <old_path> <new_path>
-    git rm <path>
-
-### Commit options: -m, -a, --amend
-
-    git commit -m "<message>"
-    git commit -a             # skip `git add` and commit all changes
-    git commit --amend        # DO before pushing, DON'T after pushing
-
-## Alice knows how to discard undesired changes: reset, checkout, revert
-
-Fix cache (aka index, staging area), then working directory:
-
-    git reset HEAD <file>   # resets index, keeps changes in working directory
-    git checkout -- <file>  # discards changes from working directory
-
-Restore working directory after things got messed up entirely:
-
-    git reset --hard HEAD
-    git reset --hard <commit> # DO before pushing, DON'T after pushing
-
-Compensate a bad commit (can be done any time):
-
-    git revert <commit>
-
-# Session 2: Bob joins Alice to work together
-
-    [bob@sidp ~]$ git config --global --list
-    user.name=Bob the Builder
-    user.email=bob@builders.com
-    color.ui=true
-    core.safecrlf=warn
-    core.autocrlf=input
-
-## Bob gets a copy of Alice's repository: clone, remote, branch
-
-    cd ~/repositories
-    git clone --origin alice ~alice/repositories/cci_cm_demo_src
-
-    git branch        # view local branches
-    git branch -r     # view remote tracking branches
-    git branch -a     # view all branches
-
-## Bob retrieves changes made by Alice: fetch, pull
-
-    git fetch alice # updates remote tracking branches only
-    git pull        # merge changes into active local branch
-
-## Alice integrates changes made by Bob: remote add, remote show
-
-Alice adds a remote alias to Bob's repository:
-
-    git remote add bob ~bob/repositories/cci_cm_demo_src
-    git remote -v
-    git remote show bob
-
-Alice can pull in Bob's changes any time as follows:
-
-    git fetch bob         # update remote-tracking branches
-    git pull bob master   # merge `bob/master` into active local branch
-
-# Session 3: Alice & Bob use a Git server
-
-Reasons:
-
-* Repositories by Alice and Bob may not always be available.
-* Complex topology if more friends join.
-* A maintained server has **24/7 availability and simple topology**.
-* Even with a central server, **each collaborator keeps the full
-  history** and does not depend on the server (they can work
-  off-line). The architecture is **fully distributed**, explaining why
-  Git is called a **Distributed Version Control System (DVCS)**.
-
-## Alice and Bob setup their ssh keys: ssh-keygen
-
-Alice does this (and so does Bob):
-
-1. Get account on a Git server, for example EODC's GitLab.
-2. Create an ssh public+private key pair with `ssh-keygen`.
-3. Upload public key onto Git server.
-4. Load private key into a local ssh agent.
-
-## Alice creates an empty repository on the Git server
-
-Alice logs on to EODC GitLab (https://git.eodc.eu), navigates to a
-GitLab group of her choice, and presses the *New project* button.
-
-She puts in the repository name (e.g. `cci_cm_demo_src`), a brief
-description, and chooses verbosity level `private`.
-
-## Alice puts her repository onto the Git server: remote, push
-
-    git remote add eodc git@git.eodc.eu:cci-sm-work/cci_cm_demo_src.git
-    git remote show eodc
-
-    git push -u eodc master:master # semantics: <local_branch>:<remote_branch>
-    git branch -a
-
-The -u (--set-upstream) flag adds an upstream (tracking) reference,
-which is used by argument-less "git pull" and other commands.
-
-## Bob clones from the Git server: --origin

(Diff truncated)

diff --git a/GitTutorial/References.mdwn b/GitTutorial/References.mdwn
index 915b8ee..641cb47 100644
--- a/GitTutorial/References.mdwn
+++ b/GitTutorial/References.mdwn
@@ -1,4 +1,4 @@
-# How Alice and Bob find help: README_GIT.md, git-help, EODC
+# Session 5: How Alice and Bob find help
 
 * README_GIT.md in repository [`cci_cm_work_doc`](https://git.eodc.eu/cci-sm-work/cci_sm_work_doc).
 * Tutorials and cheatsheets on the Internet.

diff --git a/GitTutorial/References.mdwn b/GitTutorial/References.mdwn
new file mode 100644
index 0000000..915b8ee
--- /dev/null
+++ b/GitTutorial/References.mdwn
@@ -0,0 +1,9 @@
+# How Alice and Bob find help: README_GIT.md, git-help, EODC
+
+* README_GIT.md in repository [`cci_cm_work_doc`](https://git.eodc.eu/cci-sm-work/cci_sm_work_doc).
+* Tutorials and cheatsheets on the Internet.
+* Git manual pages: `git help`
+* EODC User Support and Configuration Management: A job for Bob.
+* [Git homepage](http://git-scm.com/)
+* [Git book](http://git-scm.com/book/en/v2)
+* [GitLab](http://doc.gitlab.com/)

diff --git a/GitTutorial/BrangingAndMerging.mdwn b/GitTutorial/BrangingAndMerging.mdwn
new file mode 100644
index 0000000..3bb722d
--- /dev/null
+++ b/GitTutorial/BrangingAndMerging.mdwn
@@ -0,0 +1,144 @@
+# Session 4: Alice & Bob become Git experts by branching and merging
+
+## Alice & Bob define the branching policy
+
+Here is a branching policy for a data centre:
+
+     (L3) Temporary branches for hot fixes: '<issue>_hotfix'
+     (L2) Permanent branch for operations system: 'ops'
+     (L1) Permanent branch for test system: 'tst'
+     (L0) Permanent branch for development: 'master'
+    (L-1) Temporary branches for feature implementation: '<feature>_impl'
+
+Merging from upper to lower level is a safe action and can be done
+frequently. Merging from lower to upper level must be done with care
+and is considered a "delivery".
+
+## Alice creates the permanent branches: checkout -b, checkout, gitk, push -u
+
+Branch `master` doesn't need to be created. It is created by Git and
+always there.
+
+Create local branches (use -b flag):
+
+    git checkout -b tst                # starting from HEAD
+    git checkout -b ops <start_point>  # starting from start_point (e.g. commit)
+
+Switch between branches:
+
+    git status # always make sure to have a clean working directory!
+    git checkout <branch>
+
+Add commits to each branch, then use the graphical repository browser
+for the inspection (may sometimes be more convenient than `git log`
+and `git diff`):
+
+    gitk &
+
+Push branches to Git server (use -u flag):
+
+    git push -u <remote> <local_branch>:<remote_branch>
+    git push -u eodc tst:tst
+    git push -u eodc ops:ops
+
+## Bob gets the new remote branches: checkout -t
+
+    git fetch eodc              # update remote tracking branches
+    git branch -a               # view list of branches
+    git checkout -t eodc/tst    # use -t to set up "upstream" configuration
+    git checkout -t eodc/ops
+
+## Bob delivers work on a feature branch: checkout -b, push -u, *merge request*
+
+    git checkout master
+    git checkout -b <feature>_impl
+
+He does some work, then stages and commits it:
+
+    git add <file>...
+    git commit
+
+    git push -u eodc <feature>_impl:<feature>_impl
+
+Finally, Bob submits a merge request to Alice (talk, send an email, or
+press GitLab's *New Merge Request* button).
+
+## Alice integrates Bob's changes: merge, tag, branch -d
+
+    git fetch eodc
+    git checkout -t eodc/<feature>_impl
+
+Alice can and should inspect the changes made by Bob. She talks to him
+in case of disagreement.
+
+Alice merges feature branch into master:
+
+    git checkout master
+    git merge --no-commit <feature>_impl # Don't abuse --no-commit!
+    git status
+    git diff
+
+In case of conflicts, Alice resolves them. She also has the option to
+abort the merge. See the sections on *conflict resolution* and
+*aborting* below.
+
+If everything OK, Alice commits and tags:
+
+    git commit
+    git tag -a -m "DCR-001: Feature XYZ" DCR-001-0
+
+Alice pushes to Git server and removes obsolete feature branch:
+
+    git push eodc master
+    git branch -d <feature>_impl    # delete local branch
+    git push eodc :<feature>_impl   # delete remote branch
+
+Alice notifies Bob about integration action.
+
+## Bob verifies integration: fetch --prune
+
+    git fetch eodc           # fetch is additive, it doesn't delete branches
+    git fetch --prune eodc   # prune obsolete remote tracking branches
+    git checkout master
+    git pull
+    gitk &
+    git branch -d <feature>_impl
+
+## Alice's options for conflict resolution: checkout --ours|--theirs|-m, add
+
+When a `git merge` reports about conflicts:
+
+* Look at the diffs: `git diff` will show a three-way diff,
+  highlighting changes from both the HEAD and MERGE_HEAD versions.
+* Look at the diffs from each branch: `git log --merge -p <path>` will
+  show diffs first for the HEAD version and then the MERGE_HEAD
+  version.
+* Look at the originals: `git show :1:filename` shows the common
+  ancestor, `git show :2:filename` shows the HEAD version, and `git
+  show :3:filename` shows the MERGE_HEAD version.
+
+Alice can use the following commands in order to resolve conflicts:
+
+    git checkout --ours -- <file>
+    git checkout --theirs -- <file>
+    git checkout -m -- <file>        # gets conflicts back
+    vi <file>                        # find conflict markers and fix things
+
+    git add <file>                   # mark conflict as resolved.
+    git commit
+
+## Alice's options for aborting a failed merge: merge --abort, reset --hard, revert -m 1
+
+If things go entirely wrong, the merge can be aborted **before
+committing** by one of the following commands:
+
+    git merge --abort                # requires a newer Git version
+    git reset --hard HEAD
+
+Revert the merge after committing but **before pushing** as follows:
+
+    git reset --hard HEAD^
+
+Revert the merge after pushing as follows:
+
+    git revert -m 1 <commit>

diff --git a/GitTutorial/GitServer.mdwn b/GitTutorial/GitServer.mdwn
new file mode 100644
index 0000000..9ea4337
--- /dev/null
+++ b/GitTutorial/GitServer.mdwn
@@ -0,0 +1,45 @@
+# Session 3: Alice & Bob use a Git server
+
+Reasons:
+
+* Repositories by Alice and Bob may not always be available.
+* Complex topology if more friends join.
+* A maintained server has **24/7 availability and simple topology**.
+* Even with a central server, **each collaborator keeps the full
+  history** and does not depend on the server (they can work
+  off-line). The architecture is **fully distributed**, explaining why
+  Git is called a **Distributed Version Control System (DVCS)**.
+
+## Alice and Bob setup their ssh keys: ssh-keygen
+
+Alice does this (and so does Bob):
+
+1. Get account on a Git server, for example EODC's GitLab.
+2. Create an ssh public+private key pair with `ssh-keygen`.
+3. Upload public key onto Git server.
+4. Load private key into a local ssh agent.
+
+## Alice creates an empty repository on the Git server
+
+Alice logs on to EODC GitLab (https://git.eodc.eu), navigates to a
+GitLab group of her choice, and presses the *New project* button.
+
+She puts in the repository name (e.g. `cci_cm_demo_src`), a brief
+description, and chooses verbosity level `private`.
+
+## Alice puts her repository onto the Git server: remote, push
+
+    git remote add eodc git@git.eodc.eu:cci-sm-work/cci_cm_demo_src.git
+    git remote show eodc
+
+    git push -u eodc master:master # semantics: <local_branch>:<remote_branch>
+    git branch -a
+
+The -u (--set-upstream) flag adds an upstream (tracking) reference,
+which is used by argument-less "git pull" and other commands.
+
+## Bob clones from the Git server: --origin
+
+    git clone --origin eodc git@git.eodc.eu:cci-sm-work/cci_cm_demo_src.git
+
+Remote alias `origin` will be used if --origin flag is not given.

diff --git a/GitTutorial/RemoteRepositories.mdwn b/GitTutorial/RemoteRepositories.mdwn
new file mode 100644
index 0000000..2ec996a
--- /dev/null
+++ b/GitTutorial/RemoteRepositories.mdwn
@@ -0,0 +1,35 @@
+# Session 2: Bob joins Alice to work together
+
+    [bob@sidp ~]$ git config --global --list
+    user.name=Bob the Builder
+    user.email=bob@builders.com
+    color.ui=true
+    core.safecrlf=warn
+    core.autocrlf=input
+
+## Bob gets a copy of Alice's repository: clone, remote, branch
+
+    cd ~/repositories
+    git clone --origin alice ~alice/repositories/cci_cm_demo_src
+
+    git branch        # view local branches
+    git branch -r     # view remote tracking branches
+    git branch -a     # view all branches
+
+## Bob retrieves changes made by Alice: fetch, pull
+
+    git fetch alice # updates remote tracking branches only
+    git pull        # merge changes into active local branch
+
+## Alice integrates changes made by Bob: remote add, remote show
+
+Alice adds a remote alias to Bob's repository:
+
+    git remote add bob ~bob/repositories/cci_cm_demo_src
+    git remote -v
+    git remote show bob
+
+Alice can pull in Bob's changes any time as follows:
+
+    git fetch bob         # update remote-tracking branches
+    git pull bob master   # merge `bob/master` into active local branch

diff --git a/GitTutorial/PrivateRepository.mdwn b/GitTutorial/PrivateRepository.mdwn
new file mode 100644
index 0000000..d4f9772
--- /dev/null
+++ b/GitTutorial/PrivateRepository.mdwn
@@ -0,0 +1,99 @@
+# Session 1: Alice starts with a private repository
+
+Why is Alice using a version control system:
+
+* It is easy to manage a few files. But for 100 files and more, she needs tool support.
+* She finds web up- and download clumsy. If the file is on the web, then it is not there where she needs it for work: on her local file system
+* For files used in collaboration, she wants to know who made the change, when, and for what purpose.
+
+Why is Alice using Git:
+
+* Git development was initiated by Linus Torvalds, the developer of the Linux kernel. That indicates quality.
+* For about two years (or more) Open Source Software (OSS) developers seem to prefer Git and GitHub.
+* She works for the ESA wonderland. The ESA Thematic Exploitation Platform (TEP) Reference Architecture and Standards recommend Git (see OSS Best Practices).
+* She has a friend who has partners and clients who did not choose a common standard. He had to learn them all: ClearCase, CVS, Subversion, Git, etc.
+* She knows EODC. They `push` collaboration and `pull` standards from GitLab.
+
+## Alice configures her Git client: config --global|--list
+
+Set user's global options (on Linux):
+
+    git config --global user.name "Alice from Wonderland"
+    git config --global user.email alice@wonderland.net
+    git config --global color.ui true
+    git config --global core.safecrlf warn
+    git config --global core.autocrlf input
+
+On Windows, set `core.autocrlf` to `true`.
+
+Check user's global options with: `git config --global --list`
+
+## Alice turns a directory into a Git repository: init, add, commit
+
+It's just `init`, `add` and `commit`, but to get standardization of line endings (LF), and to exclude generated files, she does a little bit more:
+
+    cd <dir>               # for example `cci_cm_demo_src`
+    git init
+    git status
+    git add .gitattributes
+    git add .gitignore
+    git add .
+    git status
+    git commit
+    git checkout HEAD -- . # remove CRLF from working directory, if any
+    git status
+    git log
+
+Here is a procedure for automatically fixing all line endings after changing `core.autocrlf` option or `.gitattributes` file:
+
+    git status           # check status
+    git add . -u         # Save current files, so that no work is lost
+    git commit -m "Save files before refreshing line endings."
+    git rm --cached -r . # remove every file from index (cache, staging area)
+    git reset --hard     # rewrite index to pick up all new line endings
+    git add .            # add changed files back
+    git commit -m "Normalize all line endings."
+
+## Alice edits files: status, diff, add, commit, log
+
+    vi <file>
+
+    git status
+    git diff
+    git add <file>
+    git diff --cached
+    git status
+    git commit
+    git status
+
+    git log
+    git log --oneline
+    git log --name-status
+    git log -p
+
+### Move and remove files or directories: mv, rm
+
+    git mv <old_path> <new_path>
+    git rm <path>
+
+### Commit options: -m, -a, --amend
+
+    git commit -m "<message>"
+    git commit -a             # skip `git add` and commit all changes
+    git commit --amend        # DO before pushing, DON'T after pushing
+
+## Alice knows how to discard undesired changes: reset, checkout, revert
+
+Fix cache (aka index, staging area), then working directory:
+
+    git reset HEAD <file>   # resets index, keeps changes in working directory
+    git checkout -- <file>  # discards changes from working directory
+
+Restore working directory after things got messed up entirely:
+
+    git reset --hard HEAD
+    git reset --hard <commit> # DO before pushing, DON'T after pushing
+
+Compensate a bad commit (can be done any time):
+
+    git revert <commit>

diff --git a/GitTutorial.mdwn b/GitTutorial.mdwn
index 658e3d9..1a10aa3 100644
--- a/GitTutorial.mdwn
+++ b/GitTutorial.mdwn
@@ -2,6 +2,12 @@ title: Git Tutorial and Demo for CCI Soil Moisture Phase 2 Project Meeting #2
 author: Martin Ertl (AWST)
 date: June 18, 2015
 
+* [[!traillink  PrivateRepository]]
+* [[!traillink  RemoteRepositories]]
+* [[!traillink  GitServer]]
+* [[!traillink  BrangingAndMerging]]
+* [[!traillink  References]]
+
 # Session 1: Alice starts with a private repository
 
 Why is Alice using a version control system:

diff --git a/index.mdwn b/index.mdwn
index 806331e..99e1010 100644
--- a/index.mdwn
+++ b/index.mdwn
@@ -1,4 +1,4 @@
-This wiki is under construction. Until further notice I am using it for exploring Branchable and Ikiwiki.
+This wiki is under construction. Until further notice I am using it for exploring Branchable and [[Ikiwiki]].
 
 Here is the Bob & Alice [[GitTutorial]].
 

diff --git a/GitTutorial.mdwn b/GitTutorial.mdwn
new file mode 100644
index 0000000..658e3d9
--- /dev/null
+++ b/GitTutorial.mdwn
@@ -0,0 +1,355 @@
+title: Git Tutorial and Demo for CCI Soil Moisture Phase 2 Project Meeting #2
+author: Martin Ertl (AWST)
+date: June 18, 2015
+
+# Session 1: Alice starts with a private repository
+
+Why is Alice using a version control system:
+
+* It is easy to manage a few files. But for 100 files and more, she
+  needs tool support.
+* She finds web up- and download clumsy. If the file is on the web,
+  then it is not there where she needs it for work: on her local file
+  system
+* For files used in collaboration, she wants to know who made the
+  change, when, and for what purpose.
+
+Why is Alice using Git:
+
+* Git development was initiated by Linus Torvalds, the developer of
+  the Linux kernel. That indicates quality.
+* For about two years (or more) Open Source Software (OSS) developers
+  seem to prefer Git and GitHub.
+* She works for the ESA wonderland. The ESA Thematic Exploitation
+  Platform (TEP) Reference Architecture and Standards recommend Git
+  (see OSS Best Practices).
+* She has a friend who has partners and clients who did not choose a
+  common standard. He had to learn them all: ClearCase, CVS,
+  Subversion, Git, etc.
+* She knows EODC. They `push` collaboration and `pull` standards from
+  GitLab.
+
+## Alice configures her Git client: config --global|--list
+
+Set user's global options (on Linux):
+
+    git config --global user.name "Alice from Wonderland"
+    git config --global user.email alice@wonderland.net
+    git config --global color.ui true
+    git config --global core.safecrlf warn
+    git config --global core.autocrlf input
+
+On Windows, set `core.autocrlf` to `true`.
+
+Check user's global options with: `git config --global --list`
+
+## Alice turns a directory into a Git repository: init, add, commit
+
+It's just `init`, `add` and `commit`, but to get standardization of
+line endings (LF), and to exclude generated files, she does a little
+bit more:
+
+    cd <dir>               # for example `cci_cm_demo_src`
+    git init
+    git status
+    git add .gitattributes
+    git add .gitignore
+    git add .
+    git status
+    git commit
+    git checkout HEAD -- . # remove CRLF from working directory, if any
+    git status
+    git log
+
+Here is a procedure for automatically fixing all line endings after
+changing `core.autocrlf` option or `.gitattributes` file:
+
+    git status           # check status
+    git add . -u         # Save current files, so that no work is lost
+    git commit -m "Save files before refreshing line endings."
+    git rm --cached -r . # remove every file from index (cache, staging area)
+    git reset --hard     # rewrite index to pick up all new line endings
+    git add .            # add changed files back
+    git commit -m "Normalize all line endings."
+
+## Alice edits files: status, diff, add, commit, log
+
+    vi <file>
+
+    git status
+    git diff
+    git add <file>
+    git diff --cached
+    git status
+    git commit
+    git status
+
+    git log
+    git log --oneline
+    git log --name-status
+    git log -p
+
+### Move and remove files or directories: mv, rm
+
+    git mv <old_path> <new_path>
+    git rm <path>
+
+### Commit options: -m, -a, --amend
+
+    git commit -m "<message>"
+    git commit -a             # skip `git add` and commit all changes
+    git commit --amend        # DO before pushing, DON'T after pushing
+
+## Alice knows how to discard undesired changes: reset, checkout, revert
+
+Fix cache (aka index, staging area), then working directory:
+
+    git reset HEAD <file>   # resets index, keeps changes in working directory
+    git checkout -- <file>  # discards changes from working directory
+
+Restore working directory after things got messed up entirely:
+
+    git reset --hard HEAD
+    git reset --hard <commit> # DO before pushing, DON'T after pushing
+
+Compensate a bad commit (can be done any time):
+
+    git revert <commit>
+
+# Session 2: Bob joins Alice to work together
+
+    [bob@sidp ~]$ git config --global --list
+    user.name=Bob the Builder
+    user.email=bob@builders.com
+    color.ui=true
+    core.safecrlf=warn
+    core.autocrlf=input
+
+## Bob gets a copy of Alice's repository: clone, remote, branch
+
+    cd ~/repositories
+    git clone --origin alice ~alice/repositories/cci_cm_demo_src
+
+    git branch        # view local branches
+    git branch -r     # view remote tracking branches
+    git branch -a     # view all branches
+
+## Bob retrieves changes made by Alice: fetch, pull
+
+    git fetch alice # updates remote tracking branches only
+    git pull        # merge changes into active local branch
+
+## Alice integrates changes made by Bob: remote add, remote show
+
+Alice adds a remote alias to Bob's repository:
+
+    git remote add bob ~bob/repositories/cci_cm_demo_src
+    git remote -v
+    git remote show bob
+
+Alice can pull in Bob's changes any time as follows:
+
+    git fetch bob         # update remote-tracking branches
+    git pull bob master   # merge `bob/master` into active local branch
+
+# Session 3: Alice & Bob use a Git server
+
+Reasons:
+
+* Repositories by Alice and Bob may not always be available.
+* Complex topology if more friends join.
+* A maintained server has **24/7 availability and simple topology**.
+* Even with a central server, **each collaborator keeps the full
+  history** and does not depend on the server (they can work
+  off-line). The architecture is **fully distributed**, explaining why
+  Git is called a **Distributed Version Control System (DVCS)**.
+
+## Alice and Bob setup their ssh keys: ssh-keygen
+
+Alice does this (and so does Bob):
+
+1. Get account on a Git server, for example EODC's GitLab.
+2. Create an ssh public+private key pair with `ssh-keygen`.
+3. Upload public key onto Git server.
+4. Load private key into a local ssh agent.
+
+## Alice creates an empty repository on the Git server
+
+Alice logs on to EODC GitLab (https://git.eodc.eu), navigates to a
+GitLab group of her choice, and presses the *New project* button.
+
+She puts in the repository name (e.g. `cci_cm_demo_src`), a brief
+description, and chooses verbosity level `private`.
+
+## Alice puts her repository onto the Git server: remote, push
+
+    git remote add eodc git@git.eodc.eu:cci-sm-work/cci_cm_demo_src.git
+    git remote show eodc
+
+    git push -u eodc master:master # semantics: <local_branch>:<remote_branch>
+    git branch -a
+
+The -u (--set-upstream) flag adds an upstream (tracking) reference,
+which is used by argument-less "git pull" and other commands.
+

(Diff truncated)

diff --git a/index.mdwn b/index.mdwn
index f918ec0..806331e 100644
--- a/index.mdwn
+++ b/index.mdwn
@@ -1,5 +1,5 @@
 This wiki is under construction. Until further notice I am using it for exploring Branchable and Ikiwiki.
 
-Here is the Bob & Alice [[Git tutorial]].
+Here is the Bob & Alice [[GitTutorial]].
 
 All wikis are supposed to have a [[SandBox]], so this one does too.

diff --git a/Git_tutorial.mdwn b/Git_tutorial.mdwn
new file mode 100644
index 0000000..658e3d9
--- /dev/null
+++ b/Git_tutorial.mdwn
@@ -0,0 +1,355 @@
+title: Git Tutorial and Demo for CCI Soil Moisture Phase 2 Project Meeting #2
+author: Martin Ertl (AWST)
+date: June 18, 2015
+
+# Session 1: Alice starts with a private repository
+
+Why is Alice using a version control system:
+
+* It is easy to manage a few files. But for 100 files and more, she
+  needs tool support.
+* She finds web up- and download clumsy. If the file is on the web,
+  then it is not there where she needs it for work: on her local file
+  system
+* For files used in collaboration, she wants to know who made the
+  change, when, and for what purpose.
+
+Why is Alice using Git:
+
+* Git development was initiated by Linus Torvalds, the developer of
+  the Linux kernel. That indicates quality.
+* For about two years (or more) Open Source Software (OSS) developers
+  seem to prefer Git and GitHub.
+* She works for the ESA wonderland. The ESA Thematic Exploitation
+  Platform (TEP) Reference Architecture and Standards recommend Git
+  (see OSS Best Practices).
+* She has a friend who has partners and clients who did not choose a
+  common standard. He had to learn them all: ClearCase, CVS,
+  Subversion, Git, etc.
+* She knows EODC. They `push` collaboration and `pull` standards from
+  GitLab.
+
+## Alice configures her Git client: config --global|--list
+
+Set user's global options (on Linux):
+
+    git config --global user.name "Alice from Wonderland"
+    git config --global user.email alice@wonderland.net
+    git config --global color.ui true
+    git config --global core.safecrlf warn
+    git config --global core.autocrlf input
+
+On Windows, set `core.autocrlf` to `true`.
+
+Check user's global options with: `git config --global --list`
+
+## Alice turns a directory into a Git repository: init, add, commit
+
+It's just `init`, `add` and `commit`, but to get standardization of
+line endings (LF), and to exclude generated files, she does a little
+bit more:
+
+    cd <dir>               # for example `cci_cm_demo_src`
+    git init
+    git status
+    git add .gitattributes
+    git add .gitignore
+    git add .
+    git status
+    git commit
+    git checkout HEAD -- . # remove CRLF from working directory, if any
+    git status
+    git log
+
+Here is a procedure for automatically fixing all line endings after
+changing `core.autocrlf` option or `.gitattributes` file:
+
+    git status           # check status
+    git add . -u         # Save current files, so that no work is lost
+    git commit -m "Save files before refreshing line endings."
+    git rm --cached -r . # remove every file from index (cache, staging area)
+    git reset --hard     # rewrite index to pick up all new line endings
+    git add .            # add changed files back
+    git commit -m "Normalize all line endings."
+
+## Alice edits files: status, diff, add, commit, log
+
+    vi <file>
+
+    git status
+    git diff
+    git add <file>
+    git diff --cached
+    git status
+    git commit
+    git status
+
+    git log
+    git log --oneline
+    git log --name-status
+    git log -p
+
+### Move and remove files or directories: mv, rm
+
+    git mv <old_path> <new_path>
+    git rm <path>
+
+### Commit options: -m, -a, --amend
+
+    git commit -m "<message>"
+    git commit -a             # skip `git add` and commit all changes
+    git commit --amend        # DO before pushing, DON'T after pushing
+
+## Alice knows how to discard undesired changes: reset, checkout, revert
+
+Fix cache (aka index, staging area), then working directory:
+
+    git reset HEAD <file>   # resets index, keeps changes in working directory
+    git checkout -- <file>  # discards changes from working directory
+
+Restore working directory after things got messed up entirely:
+
+    git reset --hard HEAD
+    git reset --hard <commit> # DO before pushing, DON'T after pushing
+
+Compensate a bad commit (can be done any time):
+
+    git revert <commit>
+
+# Session 2: Bob joins Alice to work together
+
+    [bob@sidp ~]$ git config --global --list
+    user.name=Bob the Builder
+    user.email=bob@builders.com
+    color.ui=true
+    core.safecrlf=warn
+    core.autocrlf=input
+
+## Bob gets a copy of Alice's repository: clone, remote, branch
+
+    cd ~/repositories
+    git clone --origin alice ~alice/repositories/cci_cm_demo_src
+
+    git branch        # view local branches
+    git branch -r     # view remote tracking branches
+    git branch -a     # view all branches
+
+## Bob retrieves changes made by Alice: fetch, pull
+
+    git fetch alice # updates remote tracking branches only
+    git pull        # merge changes into active local branch
+
+## Alice integrates changes made by Bob: remote add, remote show
+
+Alice adds a remote alias to Bob's repository:
+
+    git remote add bob ~bob/repositories/cci_cm_demo_src
+    git remote -v
+    git remote show bob
+
+Alice can pull in Bob's changes any time as follows:
+
+    git fetch bob         # update remote-tracking branches
+    git pull bob master   # merge `bob/master` into active local branch
+
+# Session 3: Alice & Bob use a Git server
+
+Reasons:
+
+* Repositories by Alice and Bob may not always be available.
+* Complex topology if more friends join.
+* A maintained server has **24/7 availability and simple topology**.
+* Even with a central server, **each collaborator keeps the full
+  history** and does not depend on the server (they can work
+  off-line). The architecture is **fully distributed**, explaining why
+  Git is called a **Distributed Version Control System (DVCS)**.
+
+## Alice and Bob setup their ssh keys: ssh-keygen
+
+Alice does this (and so does Bob):
+
+1. Get account on a Git server, for example EODC's GitLab.
+2. Create an ssh public+private key pair with `ssh-keygen`.
+3. Upload public key onto Git server.
+4. Load private key into a local ssh agent.
+
+## Alice creates an empty repository on the Git server
+
+Alice logs on to EODC GitLab (https://git.eodc.eu), navigates to a
+GitLab group of her choice, and presses the *New project* button.
+
+She puts in the repository name (e.g. `cci_cm_demo_src`), a brief
+description, and chooses verbosity level `private`.
+
+## Alice puts her repository onto the Git server: remote, push
+
+    git remote add eodc git@git.eodc.eu:cci-sm-work/cci_cm_demo_src.git
+    git remote show eodc
+
+    git push -u eodc master:master # semantics: <local_branch>:<remote_branch>
+    git branch -a
+
+The -u (--set-upstream) flag adds an upstream (tracking) reference,
+which is used by argument-less "git pull" and other commands.
+

(Diff truncated)

diff --git a/index.mdwn b/index.mdwn
index 806331e..f918ec0 100644
--- a/index.mdwn
+++ b/index.mdwn
@@ -1,5 +1,5 @@
 This wiki is under construction. Until further notice I am using it for exploring Branchable and Ikiwiki.
 
-Here is the Bob & Alice [[GitTutorial]].
+Here is the Bob & Alice [[Git tutorial]].
 
 All wikis are supposed to have a [[SandBox]], so this one does too.

diff --git a/index.mdwn b/index.mdwn
index f3a2d22..806331e 100644
--- a/index.mdwn
+++ b/index.mdwn
@@ -1,5 +1,5 @@
 This wiki is under construction. Until further notice I am using it for exploring Branchable and Ikiwiki.
 
-Here is the Bob & Alice [[Gittutorial]].
+Here is the Bob & Alice [[GitTutorial]].
 
 All wikis are supposed to have a [[SandBox]], so this one does too.

diff --git a/gittutorial.mdwn b/gittutorial.mdwn
deleted file mode 100644
index 658e3d9..0000000
--- a/gittutorial.mdwn
+++ /dev/null
@@ -1,355 +0,0 @@
-title: Git Tutorial and Demo for CCI Soil Moisture Phase 2 Project Meeting #2
-author: Martin Ertl (AWST)
-date: June 18, 2015
-
-# Session 1: Alice starts with a private repository
-
-Why is Alice using a version control system:
-
-* It is easy to manage a few files. But for 100 files and more, she
-  needs tool support.
-* She finds web up- and download clumsy. If the file is on the web,
-  then it is not there where she needs it for work: on her local file
-  system
-* For files used in collaboration, she wants to know who made the
-  change, when, and for what purpose.
-
-Why is Alice using Git:
-
-* Git development was initiated by Linus Torvalds, the developer of
-  the Linux kernel. That indicates quality.
-* For about two years (or more) Open Source Software (OSS) developers
-  seem to prefer Git and GitHub.
-* She works for the ESA wonderland. The ESA Thematic Exploitation
-  Platform (TEP) Reference Architecture and Standards recommend Git
-  (see OSS Best Practices).
-* She has a friend who has partners and clients who did not choose a
-  common standard. He had to learn them all: ClearCase, CVS,
-  Subversion, Git, etc.
-* She knows EODC. They `push` collaboration and `pull` standards from
-  GitLab.
-
-## Alice configures her Git client: config --global|--list
-
-Set user's global options (on Linux):
-
-    git config --global user.name "Alice from Wonderland"
-    git config --global user.email alice@wonderland.net
-    git config --global color.ui true
-    git config --global core.safecrlf warn
-    git config --global core.autocrlf input
-
-On Windows, set `core.autocrlf` to `true`.
-
-Check user's global options with: `git config --global --list`
-
-## Alice turns a directory into a Git repository: init, add, commit
-
-It's just `init`, `add` and `commit`, but to get standardization of
-line endings (LF), and to exclude generated files, she does a little
-bit more:
-
-    cd <dir>               # for example `cci_cm_demo_src`
-    git init
-    git status
-    git add .gitattributes
-    git add .gitignore
-    git add .
-    git status
-    git commit
-    git checkout HEAD -- . # remove CRLF from working directory, if any
-    git status
-    git log
-
-Here is a procedure for automatically fixing all line endings after
-changing `core.autocrlf` option or `.gitattributes` file:
-
-    git status           # check status
-    git add . -u         # Save current files, so that no work is lost
-    git commit -m "Save files before refreshing line endings."
-    git rm --cached -r . # remove every file from index (cache, staging area)
-    git reset --hard     # rewrite index to pick up all new line endings
-    git add .            # add changed files back
-    git commit -m "Normalize all line endings."
-
-## Alice edits files: status, diff, add, commit, log
-
-    vi <file>
-
-    git status
-    git diff
-    git add <file>
-    git diff --cached
-    git status
-    git commit
-    git status
-
-    git log
-    git log --oneline
-    git log --name-status
-    git log -p
-
-### Move and remove files or directories: mv, rm
-
-    git mv <old_path> <new_path>
-    git rm <path>
-
-### Commit options: -m, -a, --amend
-
-    git commit -m "<message>"
-    git commit -a             # skip `git add` and commit all changes
-    git commit --amend        # DO before pushing, DON'T after pushing
-
-## Alice knows how to discard undesired changes: reset, checkout, revert
-
-Fix cache (aka index, staging area), then working directory:
-
-    git reset HEAD <file>   # resets index, keeps changes in working directory
-    git checkout -- <file>  # discards changes from working directory
-
-Restore working directory after things got messed up entirely:
-
-    git reset --hard HEAD
-    git reset --hard <commit> # DO before pushing, DON'T after pushing
-
-Compensate a bad commit (can be done any time):
-
-    git revert <commit>
-
-# Session 2: Bob joins Alice to work together
-
-    [bob@sidp ~]$ git config --global --list
-    user.name=Bob the Builder
-    user.email=bob@builders.com
-    color.ui=true
-    core.safecrlf=warn
-    core.autocrlf=input
-
-## Bob gets a copy of Alice's repository: clone, remote, branch
-
-    cd ~/repositories
-    git clone --origin alice ~alice/repositories/cci_cm_demo_src
-
-    git branch        # view local branches
-    git branch -r     # view remote tracking branches
-    git branch -a     # view all branches
-
-## Bob retrieves changes made by Alice: fetch, pull
-
-    git fetch alice # updates remote tracking branches only
-    git pull        # merge changes into active local branch
-
-## Alice integrates changes made by Bob: remote add, remote show
-
-Alice adds a remote alias to Bob's repository:
-
-    git remote add bob ~bob/repositories/cci_cm_demo_src
-    git remote -v
-    git remote show bob
-
-Alice can pull in Bob's changes any time as follows:
-
-    git fetch bob         # update remote-tracking branches
-    git pull bob master   # merge `bob/master` into active local branch
-
-# Session 3: Alice & Bob use a Git server
-
-Reasons:
-
-* Repositories by Alice and Bob may not always be available.
-* Complex topology if more friends join.
-* A maintained server has **24/7 availability and simple topology**.
-* Even with a central server, **each collaborator keeps the full
-  history** and does not depend on the server (they can work
-  off-line). The architecture is **fully distributed**, explaining why
-  Git is called a **Distributed Version Control System (DVCS)**.
-
-## Alice and Bob setup their ssh keys: ssh-keygen
-
-Alice does this (and so does Bob):
-
-1. Get account on a Git server, for example EODC's GitLab.
-2. Create an ssh public+private key pair with `ssh-keygen`.
-3. Upload public key onto Git server.
-4. Load private key into a local ssh agent.
-
-## Alice creates an empty repository on the Git server
-
-Alice logs on to EODC GitLab (https://git.eodc.eu), navigates to a
-GitLab group of her choice, and presses the *New project* button.
-
-She puts in the repository name (e.g. `cci_cm_demo_src`), a brief
-description, and chooses verbosity level `private`.
-
-## Alice puts her repository onto the Git server: remote, push
-
-    git remote add eodc git@git.eodc.eu:cci-sm-work/cci_cm_demo_src.git
-    git remote show eodc
-
-    git push -u eodc master:master # semantics: <local_branch>:<remote_branch>
-    git branch -a
-
-The -u (--set-upstream) flag adds an upstream (tracking) reference,
-which is used by argument-less "git pull" and other commands.
-

(Diff truncated)

diff --git a/index.mdwn b/index.mdwn
index 806331e..f3a2d22 100644
--- a/index.mdwn
+++ b/index.mdwn
@@ -1,5 +1,5 @@
 This wiki is under construction. Until further notice I am using it for exploring Branchable and Ikiwiki.
 
-Here is the Bob & Alice [[GitTutorial]].
+Here is the Bob & Alice [[Gittutorial]].
 
 All wikis are supposed to have a [[SandBox]], so this one does too.

diff --git a/GitTutorial.mdwn b/GitTutorial.mdwn
deleted file mode 100644
index 658e3d9..0000000
--- a/GitTutorial.mdwn
+++ /dev/null
@@ -1,355 +0,0 @@
-title: Git Tutorial and Demo for CCI Soil Moisture Phase 2 Project Meeting #2
-author: Martin Ertl (AWST)
-date: June 18, 2015
-
-# Session 1: Alice starts with a private repository
-
-Why is Alice using a version control system:
-
-* It is easy to manage a few files. But for 100 files and more, she
-  needs tool support.
-* She finds web up- and download clumsy. If the file is on the web,
-  then it is not there where she needs it for work: on her local file
-  system
-* For files used in collaboration, she wants to know who made the
-  change, when, and for what purpose.
-
-Why is Alice using Git:
-
-* Git development was initiated by Linus Torvalds, the developer of
-  the Linux kernel. That indicates quality.
-* For about two years (or more) Open Source Software (OSS) developers
-  seem to prefer Git and GitHub.
-* She works for the ESA wonderland. The ESA Thematic Exploitation
-  Platform (TEP) Reference Architecture and Standards recommend Git
-  (see OSS Best Practices).
-* She has a friend who has partners and clients who did not choose a
-  common standard. He had to learn them all: ClearCase, CVS,
-  Subversion, Git, etc.
-* She knows EODC. They `push` collaboration and `pull` standards from
-  GitLab.
-
-## Alice configures her Git client: config --global|--list
-
-Set user's global options (on Linux):
-
-    git config --global user.name "Alice from Wonderland"
-    git config --global user.email alice@wonderland.net
-    git config --global color.ui true
-    git config --global core.safecrlf warn
-    git config --global core.autocrlf input
-
-On Windows, set `core.autocrlf` to `true`.
-
-Check user's global options with: `git config --global --list`
-
-## Alice turns a directory into a Git repository: init, add, commit
-
-It's just `init`, `add` and `commit`, but to get standardization of
-line endings (LF), and to exclude generated files, she does a little
-bit more:
-
-    cd <dir>               # for example `cci_cm_demo_src`
-    git init
-    git status
-    git add .gitattributes
-    git add .gitignore
-    git add .
-    git status
-    git commit
-    git checkout HEAD -- . # remove CRLF from working directory, if any
-    git status
-    git log
-
-Here is a procedure for automatically fixing all line endings after
-changing `core.autocrlf` option or `.gitattributes` file:
-
-    git status           # check status
-    git add . -u         # Save current files, so that no work is lost
-    git commit -m "Save files before refreshing line endings."
-    git rm --cached -r . # remove every file from index (cache, staging area)
-    git reset --hard     # rewrite index to pick up all new line endings
-    git add .            # add changed files back
-    git commit -m "Normalize all line endings."
-
-## Alice edits files: status, diff, add, commit, log
-
-    vi <file>
-
-    git status
-    git diff
-    git add <file>
-    git diff --cached
-    git status
-    git commit
-    git status
-
-    git log
-    git log --oneline
-    git log --name-status
-    git log -p
-
-### Move and remove files or directories: mv, rm
-
-    git mv <old_path> <new_path>
-    git rm <path>
-
-### Commit options: -m, -a, --amend
-
-    git commit -m "<message>"
-    git commit -a             # skip `git add` and commit all changes
-    git commit --amend        # DO before pushing, DON'T after pushing
-
-## Alice knows how to discard undesired changes: reset, checkout, revert
-
-Fix cache (aka index, staging area), then working directory:
-
-    git reset HEAD <file>   # resets index, keeps changes in working directory
-    git checkout -- <file>  # discards changes from working directory
-
-Restore working directory after things got messed up entirely:
-
-    git reset --hard HEAD
-    git reset --hard <commit> # DO before pushing, DON'T after pushing
-
-Compensate a bad commit (can be done any time):
-
-    git revert <commit>
-
-# Session 2: Bob joins Alice to work together
-
-    [bob@sidp ~]$ git config --global --list
-    user.name=Bob the Builder
-    user.email=bob@builders.com
-    color.ui=true
-    core.safecrlf=warn
-    core.autocrlf=input
-
-## Bob gets a copy of Alice's repository: clone, remote, branch
-
-    cd ~/repositories
-    git clone --origin alice ~alice/repositories/cci_cm_demo_src
-
-    git branch        # view local branches
-    git branch -r     # view remote tracking branches
-    git branch -a     # view all branches
-
-## Bob retrieves changes made by Alice: fetch, pull
-
-    git fetch alice # updates remote tracking branches only
-    git pull        # merge changes into active local branch
-
-## Alice integrates changes made by Bob: remote add, remote show
-
-Alice adds a remote alias to Bob's repository:
-
-    git remote add bob ~bob/repositories/cci_cm_demo_src
-    git remote -v
-    git remote show bob
-
-Alice can pull in Bob's changes any time as follows:
-
-    git fetch bob         # update remote-tracking branches
-    git pull bob master   # merge `bob/master` into active local branch
-
-# Session 3: Alice & Bob use a Git server
-
-Reasons:
-
-* Repositories by Alice and Bob may not always be available.
-* Complex topology if more friends join.
-* A maintained server has **24/7 availability and simple topology**.
-* Even with a central server, **each collaborator keeps the full
-  history** and does not depend on the server (they can work
-  off-line). The architecture is **fully distributed**, explaining why
-  Git is called a **Distributed Version Control System (DVCS)**.
-
-## Alice and Bob setup their ssh keys: ssh-keygen
-
-Alice does this (and so does Bob):
-
-1. Get account on a Git server, for example EODC's GitLab.
-2. Create an ssh public+private key pair with `ssh-keygen`.
-3. Upload public key onto Git server.
-4. Load private key into a local ssh agent.
-
-## Alice creates an empty repository on the Git server
-
-Alice logs on to EODC GitLab (https://git.eodc.eu), navigates to a
-GitLab group of her choice, and presses the *New project* button.
-
-She puts in the repository name (e.g. `cci_cm_demo_src`), a brief
-description, and chooses verbosity level `private`.
-
-## Alice puts her repository onto the Git server: remote, push
-
-    git remote add eodc git@git.eodc.eu:cci-sm-work/cci_cm_demo_src.git
-    git remote show eodc
-
-    git push -u eodc master:master # semantics: <local_branch>:<remote_branch>
-    git branch -a
-
-The -u (--set-upstream) flag adds an upstream (tracking) reference,
-which is used by argument-less "git pull" and other commands.
-

(Diff truncated)

diff --git a/GitTutorial.mdwn b/GitTutorial.mdwn
new file mode 100644
index 0000000..658e3d9
--- /dev/null
+++ b/GitTutorial.mdwn
@@ -0,0 +1,355 @@
+title: Git Tutorial and Demo for CCI Soil Moisture Phase 2 Project Meeting #2
+author: Martin Ertl (AWST)
+date: June 18, 2015
+
+# Session 1: Alice starts with a private repository
+
+Why is Alice using a version control system:
+
+* It is easy to manage a few files. But for 100 files and more, she
+  needs tool support.
+* She finds web up- and download clumsy. If the file is on the web,
+  then it is not there where she needs it for work: on her local file
+  system
+* For files used in collaboration, she wants to know who made the
+  change, when, and for what purpose.
+
+Why is Alice using Git:
+
+* Git development was initiated by Linus Torvalds, the developer of
+  the Linux kernel. That indicates quality.
+* For about two years (or more) Open Source Software (OSS) developers
+  seem to prefer Git and GitHub.
+* She works for the ESA wonderland. The ESA Thematic Exploitation
+  Platform (TEP) Reference Architecture and Standards recommend Git
+  (see OSS Best Practices).
+* She has a friend who has partners and clients who did not choose a
+  common standard. He had to learn them all: ClearCase, CVS,
+  Subversion, Git, etc.
+* She knows EODC. They `push` collaboration and `pull` standards from
+  GitLab.
+
+## Alice configures her Git client: config --global|--list
+
+Set user's global options (on Linux):
+
+    git config --global user.name "Alice from Wonderland"
+    git config --global user.email alice@wonderland.net
+    git config --global color.ui true
+    git config --global core.safecrlf warn
+    git config --global core.autocrlf input
+
+On Windows, set `core.autocrlf` to `true`.
+
+Check user's global options with: `git config --global --list`
+
+## Alice turns a directory into a Git repository: init, add, commit
+
+It's just `init`, `add` and `commit`, but to get standardization of
+line endings (LF), and to exclude generated files, she does a little
+bit more:
+
+    cd <dir>               # for example `cci_cm_demo_src`
+    git init
+    git status
+    git add .gitattributes
+    git add .gitignore
+    git add .
+    git status
+    git commit
+    git checkout HEAD -- . # remove CRLF from working directory, if any
+    git status
+    git log
+
+Here is a procedure for automatically fixing all line endings after
+changing `core.autocrlf` option or `.gitattributes` file:
+
+    git status           # check status
+    git add . -u         # Save current files, so that no work is lost
+    git commit -m "Save files before refreshing line endings."
+    git rm --cached -r . # remove every file from index (cache, staging area)
+    git reset --hard     # rewrite index to pick up all new line endings
+    git add .            # add changed files back
+    git commit -m "Normalize all line endings."
+
+## Alice edits files: status, diff, add, commit, log
+
+    vi <file>
+
+    git status
+    git diff
+    git add <file>
+    git diff --cached
+    git status
+    git commit
+    git status
+
+    git log
+    git log --oneline
+    git log --name-status
+    git log -p
+
+### Move and remove files or directories: mv, rm
+
+    git mv <old_path> <new_path>
+    git rm <path>
+
+### Commit options: -m, -a, --amend
+
+    git commit -m "<message>"
+    git commit -a             # skip `git add` and commit all changes
+    git commit --amend        # DO before pushing, DON'T after pushing
+
+## Alice knows how to discard undesired changes: reset, checkout, revert
+
+Fix cache (aka index, staging area), then working directory:
+
+    git reset HEAD <file>   # resets index, keeps changes in working directory
+    git checkout -- <file>  # discards changes from working directory
+
+Restore working directory after things got messed up entirely:
+
+    git reset --hard HEAD
+    git reset --hard <commit> # DO before pushing, DON'T after pushing
+
+Compensate a bad commit (can be done any time):
+
+    git revert <commit>
+
+# Session 2: Bob joins Alice to work together
+
+    [bob@sidp ~]$ git config --global --list
+    user.name=Bob the Builder
+    user.email=bob@builders.com
+    color.ui=true
+    core.safecrlf=warn
+    core.autocrlf=input
+
+## Bob gets a copy of Alice's repository: clone, remote, branch
+
+    cd ~/repositories
+    git clone --origin alice ~alice/repositories/cci_cm_demo_src
+
+    git branch        # view local branches
+    git branch -r     # view remote tracking branches
+    git branch -a     # view all branches
+
+## Bob retrieves changes made by Alice: fetch, pull
+
+    git fetch alice # updates remote tracking branches only
+    git pull        # merge changes into active local branch
+
+## Alice integrates changes made by Bob: remote add, remote show
+
+Alice adds a remote alias to Bob's repository:
+
+    git remote add bob ~bob/repositories/cci_cm_demo_src
+    git remote -v
+    git remote show bob
+
+Alice can pull in Bob's changes any time as follows:
+
+    git fetch bob         # update remote-tracking branches
+    git pull bob master   # merge `bob/master` into active local branch
+
+# Session 3: Alice & Bob use a Git server
+
+Reasons:
+
+* Repositories by Alice and Bob may not always be available.
+* Complex topology if more friends join.
+* A maintained server has **24/7 availability and simple topology**.
+* Even with a central server, **each collaborator keeps the full
+  history** and does not depend on the server (they can work
+  off-line). The architecture is **fully distributed**, explaining why
+  Git is called a **Distributed Version Control System (DVCS)**.
+
+## Alice and Bob setup their ssh keys: ssh-keygen
+
+Alice does this (and so does Bob):
+
+1. Get account on a Git server, for example EODC's GitLab.
+2. Create an ssh public+private key pair with `ssh-keygen`.
+3. Upload public key onto Git server.
+4. Load private key into a local ssh agent.
+
+## Alice creates an empty repository on the Git server
+
+Alice logs on to EODC GitLab (https://git.eodc.eu), navigates to a
+GitLab group of her choice, and presses the *New project* button.
+
+She puts in the repository name (e.g. `cci_cm_demo_src`), a brief
+description, and chooses verbosity level `private`.
+
+## Alice puts her repository onto the Git server: remote, push
+
+    git remote add eodc git@git.eodc.eu:cci-sm-work/cci_cm_demo_src.git
+    git remote show eodc
+
+    git push -u eodc master:master # semantics: <local_branch>:<remote_branch>
+    git branch -a
+
+The -u (--set-upstream) flag adds an upstream (tracking) reference,
+which is used by argument-less "git pull" and other commands.
+

(Diff truncated)

diff --git a/index.mdwn b/index.mdwn
index 0c286b7..806331e 100644
--- a/index.mdwn
+++ b/index.mdwn
@@ -1,3 +1,5 @@
 This wiki is under construction. Until further notice I am using it for exploring Branchable and Ikiwiki.
 
+Here is the Bob & Alice [[GitTutorial]].
+
 All wikis are supposed to have a [[SandBox]], so this one does too.

diff --git a/index.mdwn b/index.mdwn
new file mode 100644
index 0000000..0c286b7
--- /dev/null
+++ b/index.mdwn
@@ -0,0 +1,3 @@
+This wiki is under construction. Until further notice I am using it for exploring Branchable and Ikiwiki.
+
+All wikis are supposed to have a [[SandBox]], so this one does too.

diff --git a/.gitignore b/.gitignore
new file mode 100644
index 0000000..eecda60
--- /dev/null
+++ b/.gitignore
@@ -0,0 +1 @@
+/.ikiwiki