Skip to content

Commit

Permalink
Merge pull request #2 from swcarpentry-i18n/merge-upstream-jul24
Browse files Browse the repository at this point in the history
Merge upstream changes
  • Loading branch information
tobyhodges authored Jul 31, 2024
2 parents 5790869 + 6027c63 commit a11734e
Show file tree
Hide file tree
Showing 15 changed files with 105 additions and 191 deletions.
8 changes: 4 additions & 4 deletions .github/workflows/README.md
Original file line number Diff line number Diff line change
Expand Up @@ -2,7 +2,7 @@

This directory contains workflows to be used for Lessons using the {sandpaper}
lesson infrastructure. Two of these workflows require R (`sandpaper-main.yaml`
and `pr-recieve.yaml`) and the rest are bots to handle pull request management.
and `pr-receive.yaml`) and the rest are bots to handle pull request management.

These workflows will likely change as {sandpaper} evolves, so it is important to
keep them up-to-date. To do this in your lesson you can do the following in your
Expand Down Expand Up @@ -94,7 +94,7 @@ branch called `update/workflows` and a pull request is created. Maintainers are
encouraged to review the changes and accept the pull request if the outputs
are okay.

This update is run ~~weekly or~~ on demand.
This update is run weekly or on demand.

### 03 Maintain: Update Package Cache (update-cache.yaml)

Expand Down Expand Up @@ -140,7 +140,7 @@ Once the checks are finished, a comment is issued to the pull request, which
will allow maintainers to determine if it is safe to run the
"Receive Pull Request" workflow from new contributors.

### Recieve Pull Request (pr-recieve.yaml)
### Receive Pull Request (pr-receive.yaml)

**Note of caution:** This workflow runs arbitrary code by anyone who creates a
pull request. GitHub has safeguarded the token used in this workflow to have no
Expand Down Expand Up @@ -171,7 +171,7 @@ The artifacts produced are used by the next workflow.

### Comment on Pull Request (pr-comment.yaml)

This workflow is triggered if the `pr-recieve.yaml` workflow is successful.
This workflow is triggered if the `pr-receive.yaml` workflow is successful.
The steps in this workflow are:

1. Test if the workflow is valid and comment the validity of the workflow to the
Expand Down
2 changes: 1 addition & 1 deletion .github/workflows/sandpaper-version.txt
Original file line number Diff line number Diff line change
@@ -1 +1 @@
0.16.2
0.16.5
8 changes: 3 additions & 5 deletions episodes/01-basics.md
Original file line number Diff line number Diff line change
Expand Up @@ -38,20 +38,20 @@ think of it as a recording of your progress: you can rewind to start at the base
document and play back each change you made, eventually arriving at your
more recent version.

![](fig/play-changes.svg){alt='Changes Are Saved Sequentially'}
![](fig/play-changes.svg){alt='A diagram demonstrating how a single document grows as the result of sequential changes'}

Once you think of changes as separate from the document itself, you
can then think about "playing back" different sets of changes on the base document, ultimately

Check warning on line 44 in episodes/01-basics.md

View workflow job for this annotation

GitHub Actions / Build Full Site

[missing file]: [repository(リポジトリ)]((../learners/reference.md#repository))

Check warning on line 44 in episodes/01-basics.md

View workflow job for this annotation

GitHub Actions / Build Full Site

[missing file]: [repository(リポジトリ)]((../learners/reference.md#repository))

Check warning on line 44 in episodes/01-basics.md

View workflow job for this annotation

GitHub Actions / Build Full Site

[missing file]: [repository(リポジトリ)]((../learners/reference.md#repository))

Check warning on line 44 in episodes/01-basics.md

View workflow job for this annotation

GitHub Actions / Build Full Site

[missing file]: [repository(リポジトリ)]((../learners/reference.md#repository))

Check warning on line 44 in episodes/01-basics.md

View workflow job for this annotation

GitHub Actions / Build Full Site

[missing file]: [repository(リポジトリ)]((../learners/reference.md#repository))

Check warning on line 44 in episodes/01-basics.md

View workflow job for this annotation

GitHub Actions / Build Full Site

[missing file]: [repository(リポジトリ)]((../learners/reference.md#repository))

Check warning on line 44 in episodes/01-basics.md

View workflow job for this annotation

GitHub Actions / Build Full Site

[missing file]: [repository(リポジトリ)]((../learners/reference.md#repository))
resulting in different versions of that document. For example, two users can make independent
sets of changes on the same document.

![](fig/versions.svg){alt='Different Versions Can be Saved'}
![](fig/versions.svg){alt='A diagram with one source document that has been modified in two different ways to produce two different versions of the document'}

Unless multiple users make changes to the same section of the document - a
[conflict](../learners/reference.md#conflict) - you can
incorporate two sets of changes into the same base document.

![](fig/merge.svg){alt='Multiple Versions Can be Merged'}
![](fig/merge.svg){alt='A diagram that shows the merging of two different document versions into one document that contains all of the changes from both versions'}

A version control system is a tool that keeps track of these changes for us,
effectively creating different versions of our files. It allows us to decide
Expand Down Expand Up @@ -125,5 +125,3 @@ the same files concurrently.
- Version control also allows many people to work in parallel.

::::::::::::::::::::::::::::::::::::::::::::::::::


14 changes: 6 additions & 8 deletions episodes/03-create.md
Original file line number Diff line number Diff line change
Expand Up @@ -23,7 +23,7 @@ we can start using it.
We will continue with the story of Wolfman and Dracula who are investigating if it
is possible to send a planetary lander to Mars.

![](fig/motivatingexample.png){alt='motivatingexample'}
![](fig/motivatingexample.png){alt='The main elements of the story: Dracula, Wolfman, the Mummy, Mars, Pluto and The Moon'}
[Werewolf vs dracula](https://www.deviantart.com/b-maze/art/Werewolf-vs-Dracula-124893530)
by [b-maze](https://www.deviantart.com/b-maze) / [Deviant Art](https://www.deviantart.com/).
[Mars](https://en.wikipedia.org/wiki/File:OSIRIS_Mars_true_color.jpg) by European Space Agency /
Expand Down Expand Up @@ -95,8 +95,7 @@ $ git checkout -b main
Switched to a new branch 'main'
```

We can check that everything is set up correctly
by asking Git to tell us the status of our project:
We can now start using one of the most important git commands, which is particularly helpful to beginners. `git status` tells us the status of our project, and better, a list of changes in the project and options on what to do with those changes. We can use it as often as we want, whenever we want to understand what is going on.

```bash
$ git status
Expand Down Expand Up @@ -166,7 +165,7 @@ fatal: Not a git repository (or any of the parent directories): .git
## Correcting `git init` Mistakes

Wolfman explains to Dracula how a nested repository is redundant and may cause confusion
down the road. Dracula would like to remove the nested repository. How can Dracula undo
down the road. Dracula would like to go back to a single git repository. How can Dracula undo
his last `git init` in the `moons` subdirectory?

::::::::::::::: solution
Expand All @@ -183,14 +182,14 @@ that are not tracked by Git can easily be removed like any other "ordinary" file
$ rm filename
```

Similarly a directory can be removed using `rm -r dirname` or `rm -rf dirname`.
Similarly a directory can be removed using `rm -r dirname`.
If the files or folder being removed in this fashion are tracked by Git, then their removal
becomes another change that we will need to track, as we will see in the next episode.

### Solution

Git keeps all of its files in the `.git` directory.
To recover from this little mistake, Dracula can just remove the `.git`
To recover from this little mistake, Dracula can remove the `.git`
folder in the moons subdirectory by running the following command from inside the `planets` directory:

```bash
Expand All @@ -199,6 +198,7 @@ $ rm -rf moons/.git

But be careful! Running this command in the wrong directory will remove
the entire Git history of a project you might want to keep.
In general, deleting files and directories using `rm` from the command line cannot be reversed.
Therefore, always check your current directory using the command `pwd`.


Expand All @@ -213,5 +213,3 @@ Therefore, always check your current directory using the command `pwd`.
- Git stores all of its repository data in the `.git` directory.

::::::::::::::::::::::::::::::::::::::::::::::::::


6 changes: 2 additions & 4 deletions episodes/04-changes.md
Original file line number Diff line number Diff line change
Expand Up @@ -334,7 +334,7 @@ than you would like!

::::::::::::::::::::::::::::::::::::::::::::::::::

![](fig/git-staging-area.svg){alt='The Git Staging Area'}
![](fig/git-staging-area.svg){alt='A diagram showing how "git add" registers changes in the staging area, while "git commit" moves changes from the staging area to the repository'}

Let's watch as our changes to a file move from our editor
to the staging area
Expand Down Expand Up @@ -587,7 +587,7 @@ we first need to add the changed files to the staging area
(`git add`) and then commit the staged changes to the
repository (`git commit`):

![](fig/git-committing.svg){alt='The Git Commit Workflow'}
![](fig/git-committing.svg){alt='A diagram showing two documents being separately staged using git add, before being combined into one commit using git commit'}

::::::::::::::::::::::::::::::::::::::: challenge

Expand Down Expand Up @@ -791,5 +791,3 @@ $ git diff me.txt
- Write a commit message that accurately describes your changes.

::::::::::::::::::::::::::::::::::::::::::::::::::


Loading

0 comments on commit a11734e

Please sign in to comment.