small updates in episodes

content/archaeology.md

@@ -22,7 +22,7 @@ GitHub.
 * The **GitHub** web interface allows many things to be done, but not
   everything.
 * **VS Code** allows some of these, but for some it's easier to open
-  the VS Code terminal and run git there.
+  the VS Code terminal and run Git there.
 
 
 ## Our toolbox for history inspection
@@ -200,8 +200,7 @@ modified each line. Incredibly useful for reproducibility.
 
 :::::
 
-:::{discussion}
-Discuss how these relatively trivial changes affect the annotation:
+:::{discussion} Discuss how these relatively trivial changes affect the annotation
 - Wrapping long lines of text/code into shorter lines
 - Auto-formatting tools such as `black`
 - Editors that automatically remove trailing whitespace
@@ -221,17 +220,17 @@ Discuss how these relatively trivial changes affect the annotation:
 
     Example (lines starting with "#" are only comments):
 
-    ```console
-    $ # create branch called "older-code" from hash 347e6292419b
+    ```bash
+    # create branch called "older-code" from hash 347e6292419b
     $ git switch --create older-code 347e6292419bd0e4bff077fe971f983932d7a0e9
 
-    $ # now you can navigate and inspect the code as it was back then
-    $ # ...
+    # now you can navigate and inspect the code as it was back then
+    # ...
 
-    $ # after we are done we can switch back to "main"
+    # after we are done we can switch back to "main"
     $ git switch main
 
-    $ # if we like we can delete the "older-code" branch
+    # if we like we can delete the "older-code" branch
     $ git branch -d older-code
     ```
 
@@ -272,9 +271,6 @@ Discuss how these relatively trivial changes affect the annotation:
 
 ## Exercise
 
-This is described with the command line method, but by looking above
-you can translate to the other options.
-
 :::::{exercise} Exercise: Explore basic archaeology commands (20 min)
   Let us explore the value of these commands in an exercise.  Future
   exercises do not depend on this, so it is OK if you do not complete
@@ -375,7 +371,7 @@ you can translate to the other options.
   Then using the above toolbox try to:
   1. Find the code line which contains `"Logic error in degree_correlation"`.
   1. Find out when this line was last modified or added. Find the actual commit which modified that line.
-  1. Inspect that commit with `git show`.
+  1. Inspect the commit. What is the commit change? What is the commit metadata?
   1. Create a branch pointing to the past when that commit was created to be
      able to browse and use the code as it was back then.
   1. How would you bring the code to the version of the code right before that line was last modified?
@@ -422,13 +418,11 @@ you can translate to the other options.
 
 ## Finding out when something broke/changed with `git bisect`
 
-This only works with the command line.
-
-> *"But I am sure it used to work! Strange."*
+This section only works with the command line.
 
-Sometimes you realize that something broke.
-You know that it used to work.
-You do not know when it broke.
+*"But I am sure it used to work! Strange."* - Sometimes you realize that
+something broke.  You know that it used to work.  You do not know **when precisely** it
+broke.
 
 :::{discussion} How would you solve this?
 Before we go on first discuss how you would solve this problem: You know that it worked
@@ -467,7 +461,7 @@ We will probably arrive at a solution which is similar to `git bisect`:
 
 This only works with the command line.
 
-::::{exercise} (optional) History-2: Use git bisect to find the bad commit
+::::{exercise} (optional) Use git bisect to find the bad commit
   In this exercise, we use `git bisect` on an example repository.  It
   is OK if you do not complete this exercise fully.
 

content/local-workflow.md

@@ -6,7 +6,7 @@ do, so now we move to working on your own computer.
 
 :::{objectives}
 - We are able to clone a repository from the web and modify it locally.
-- We can do the same things we did before (commit, branch, merge), but locally.
+- We can do the same things we did before (commit, branch, merge), but **locally**.
 - We get a feeling for remote repositories ([more later](https://coderefinery.github.io/git-collaborative/)).
 :::
 
@@ -29,7 +29,7 @@ do, so now we move to working on your own computer.
 
 **Cloning**:
 - Copying (downloading) the entire repository with all commits, branches, and tags to your computer.
-- It is a full backup of the repository, including all history.
+- It is a **full backup** of the repository, including all history.
 - You can then work on your local clone of the repository.
 - Changes on local clone will not automatically appear in the repository where
   we cloned from. We have to actively "push" them there (we will practice this
@@ -82,7 +82,7 @@ since we don't plan to push changes back (for step 8 it might be easier to use t
 - Or first fork the original repository and then clone your fork.
 
 The examples below assume you are cloning the original repository. If you are cloning your fork, you should
-replace `coderefinery` with your GitHub username.
+replace `cr-workshop-exercises` with your GitHub username.
 
 :::::::{tabs}
 ::::::{group-tab} Command line
@@ -234,7 +234,7 @@ Committing a new file in VS Code.
 
 1. One creates the file in the normal way,
 1. In the git tab, one uses the checkbox under "Staged" to add mark the file as {term}`staged <staging area>`, which means it will be committed next.
-1. Click the checkmarks to commit.  A new window will be opened.
+1. Click the check-mark to commit.  A new window will be opened.
 
 :::{figure} img/commits/rstudio-committing.png
 :alt: Screenshot of RStudio commit process

content/merging.md

@@ -6,7 +6,7 @@ means that we have to somehow combine the changes later. In this part we will
 practice this: {term}`merging`.
 
 :::{objectives}
-- Understand that on GitHub merging is done through a {term}`pull request`. Think of it as a change proposal.
+- Understand that on GitHub merging is done through a {term}`pull request`. Think of it as a **change proposal**.
 - Create and merge a pull request within your own repository.
 - Understand (and optionally) do the same across repositories, to contribute to
   the {term}`upstream` public repository.
@@ -25,7 +25,7 @@ practice this: {term}`merging`.
   us to test it before it becomes "live".
 * Now, we want to bring that change into the "main" branch.
 * We will find it's not that hard!  But you do have to keep track of the
-  steps and make sure that you work very precisely.
+  steps and make sure that you are careful about where a change is added.
 
 
 ## Exercise
@@ -50,22 +50,22 @@ review and commenting before the actual merge.
 :::{exercise} Exercise: Merging branches with pull requests (20 min)
 We assume that in the previous exercise you have created a new branch
 with a recipe.  In our previous example, it is called `new-recipe`.
-If not, create it first and add a recipe to your new branch, see
+If not, create the branch first and add a recipe to your new branch, see
 {doc}`commits`.
 
 We provide basic hints. You should refer to the solution as needed.
 
 1. Navigate to your branch from the previous episode
-   (Hint: the same branch view we used last time).
+   (hint: the same branch view we used last time).
 
-1. Begin the pull request process.
-   (Hint: There is a "Contribute" button in the branch view).
+1. Begin the pull request process
+   (hint: There is a "Contribute" button in the branch view).
 
 1. Add or modify the pull request title and description, and verify the other data.
    In the pull request verify the target repository and the target
    branch. Make sure that you are merging within your own repository.
    **GitHub: By default, it will offer to make the change to the
-   upstream repository, `coderefinery`.  You should change this**, you
+   upstream repository, `cr-workshop-exercises`.  You should change this**, you
    shouldn't contribute your test recipe upstream yet.  Where it says
    `base repository`, select your own user's repository.
 
@@ -77,7 +77,7 @@ We provide basic hints. You should refer to the solution as needed.
 
 1. Find out which branches are merged and thus safe to delete. Then remove them
    and verify that the commits are still there, only the branch labels are
-   gone. (Hint: you can delete branches that have been merged into `main`).
+   gone (hint: you can delete branches that have been merged into `main`).
 
 1. Optional: Try to create a new branch with a new change, then open a pull
    request but towards the central repository. We will later merge few of