Merge branch 'main' into saransh/fix-dask

ch00git/01Intro.ipynb.py

@@ -91,28 +91,28 @@
 # ## Practising with Git
 
 # %% [markdown]
-# ### Example Exercise
+# ## Example Exercise
 #
 # In this course, we will use, as an example, the development of a few text files containing a description of a topic of your choice. 
 #
 # This could be your research, a hobby, or something else. In the end, we will show you how to display the content of these files as a very simple website. 
 
 # %% [markdown]
-# ### Programming and documents
+# ## Programming and documents
 #
 # The purpose of this exercise is to learn how to use Git to manage program code you write, not simple text website content, but we'll just use these text files instead of code for now, so as not to confuse matters with trying to learn version control while thinking about programming too. 
 #
 # In later parts of the course, you will use the version control tools you learn today with actual Python code.
 
 # %% [markdown]
-# ### Markdown
+# ## Markdown
 #
 # The text files we create will use a simple "wiki" markup style called [markdown](http://daringfireball.net/projects/markdown/basics) to show formatting. This is the convention used in this file, too. 
 #
 # You can view the content of this file in the way Markdown renders it by looking on the [web](https://github.com/UCL/ucl_software_carpentry/blob/master/git/git_instructions.md), and compare the [raw text](https://raw.github.com/UCL/ucl_software_carpentry/master/git/git_instructions.md).
 
 # %% [markdown]
-# ### Displaying Text in this Tutorial
+# ## Displaying Text in this Tutorial
 #
 # This tutorial is based on use of the Git command line. So you'll be typing commands in the shell.
 
@@ -145,7 +145,7 @@
 # On either Windows, Mac or Linux, we recommend [VS Code](https://code.visualstudio.com/).
 
 # %% [markdown]
-# ### Setting up somewhere to work
+# ## Setting up somewhere to work
 
 # %% attributes={"classes": [" Bash"], "id": ""} jupyter={"outputs_hidden": false} language="bash"
 # rm -rf learning_git/git_example # Just in case it's left over from a previous class; you won't need this
@@ -173,7 +173,7 @@
 # %% [markdown]
 # ## Solo work
 #
-# ### Configuring Git with your name and email
+# ## Configuring Git with your name and email
 #
 # First, we should configure Git to know our name and email address:
 
@@ -191,7 +191,7 @@
 # Historically, the default branch was named `master`. Nowadays, the community and most of the hosting sites have changed the default ([read about this change in GitHub](https://github.com/github/renaming/) and [Gitlab](https://about.gitlab.com/blog/2021/03/10/new-git-default-branch-name/).
 
 # %% [markdown]
-# ### Initialising the repository
+# ## Initialising the repository
 #
 # Now, we will tell Git to track the content of this folder as a git "repository".
 

ch00git/02Solo.ipynb.py

@@ -12,7 +12,7 @@
 # ---
 
 # %% [markdown]
-# ## Solo work with Git
+# # Solo work with Git
 
 # %% [markdown]
 # **NOTE:** using bash/git commands is not fully supported on jupyterlite yet (due to single
@@ -31,7 +31,7 @@
 working_dir
 
 # %% [markdown]
-# ### A first example file
+# ## A first example file
 #
 # So let's create an example file, and see how to start to manage a history of changes to it.
 
@@ -50,7 +50,7 @@
 # cat index.md
 
 # %% [markdown]
-# ### Telling Git about the File
+# ## Telling Git about the File
 #
 # So, let's tell Git that `index.md` is a file which is important, and we would like to keep track of its history:
 
@@ -60,7 +60,7 @@
 # %% [markdown]
 # Don't forget: Any files in repositories which you want to "track" need to be added with `git add` after you create them.
 #
-# ### Our first commit
+# ## Our first commit
 #
 # Now, we need to tell Git to record the first version of this file in the history of changes:
 
@@ -73,7 +73,7 @@
 # There's a lot of output there you can ignore for now.
 
 # %% [markdown]
-# ### Configuring Git with your editor
+# ## Configuring Git with your editor
 #
 # If you don't type in the log message directly with -m "Some message", then an editor will pop up, to allow you
 # to edit your message on the fly.
@@ -102,7 +102,7 @@
 # I'm going to be using `nano` as my editor, but you can use whatever editor you prefer. Find how to setup your favourite editor in [the setup chapter of Software Carpentry's Git lesson](https://swcarpentry.github.io/git-novice/02-setup.html).
 
 # %% [markdown]
-# ### Git log
+# ## Git log
 #
 # Git now has one change in its history:
 
@@ -113,7 +113,7 @@
 # You can see the commit message, author, and date...
 
 # %% [markdown]
-# ### Hash Codes
+# ## Hash Codes
 #
 # The commit "hash code", e.g.
 #
@@ -124,7 +124,7 @@
 # (This is a really long code, but whenever you need to use it, you can just use the first few characters, however many characters is long enough to make it unique, `c438` for example. )
 
 # %% [markdown]
-# ### Nothing to see here
+# ## Nothing to see here
 #
 # Note that git will now tell us that our "working directory" is up-to-date with the repository: there are no changes to the files that aren't recorded in the repository history:
 
@@ -150,7 +150,7 @@
 # cat index.md
 
 # %% [markdown]
-# ### Unstaged changes
+# ## Unstaged changes
 
 # %% attributes={"classes": [" Bash"], "id": ""} jupyter={"outputs_hidden": false} language="bash"
 # git status
@@ -174,7 +174,7 @@
 # Deleted lines are prefixed with a minus, added lines prefixed with a plus.
 
 # %% [markdown]
-# ### Staging a file to be included in the next commit
+# ## Staging a file to be included in the next commit
 #
 # To include the file in the next commit, we have a few choices. This is one of the things to be careful of with git: there are lots of ways to do similar things, and it can be hard to keep track of them all.
 
@@ -187,14 +187,14 @@
 # Note that `git add` is the command we use to introduce git to a new file, but also the command we use to "stage" a file to be included in the next commit. 
 
 # %% [markdown]
-# ### The staging area
+# ## The staging area
 #
 # The "staging area" or "index" is the git jargon for the place which contains the list of changes which will be included in the next commit.
 #
 # You can include specific changes to specific files with `git add`, commit them, add some more files, and commit them. (You can even add specific changes within a file to be included in the index.)
 
 # %% [markdown]
-# ### Message Sequence Charts
+# ## Message Sequence Charts
 
 # %% [markdown]
 # In order to illustrate the behaviour of Git, it will be useful to be able to generate figures in Python
@@ -237,7 +237,7 @@ def wsd(code):
 wsd("Sender->Recipient: Hello\n Recipient->Sender: Message received OK")
 
 # %% [markdown]
-# ### The Levels of Git
+# ## The Levels of Git
 
 # %% [markdown]
 # Let's make ourselves a sequence chart to show the different aspects of Git we've seen so far:
@@ -251,7 +251,7 @@ def wsd(code):
 wsd(message)
 
 # %% [markdown]
-# ### Review of status
+# ## Review of status
 
 # %% attributes={"classes": [" Bash"], "id": ""} jupyter={"outputs_hidden": false} language="bash"
 # git status
@@ -266,7 +266,7 @@ def wsd(code):
 # Great, we now have a file which contains a mistake.
 
 # %% [markdown]
-# ### Carry on regardless
+# ## Carry on regardless
 #
 # In a while, we'll use Git to roll back to the last correct version: this is one of the main reasons we wanted to use version control, after all! But for now, let's do just as we would if we were writing code, not notice our mistake and keep working...
 
@@ -289,7 +289,7 @@ def wsd(code):
 # cat index.md
 
 # %% [markdown]
-# ### Review of changes
+# ## Review of changes
 
 # %% attributes={"classes": [" Bash"], "id": ""} jupyter={"outputs_hidden": false} language="bash"
 # git log | head
@@ -301,7 +301,7 @@ def wsd(code):
 # git log --oneline
 
 # %% [markdown]
-# ### Git Solo Workflow
+# ## Git Solo Workflow
 
 # %% [markdown]
 # We can make a diagram that summarises the above story:

ch00git/03Mistakes.ipynb.py

@@ -12,7 +12,7 @@
 # ---
 
 # %% [markdown]
-# ## Fixing mistakes
+# # Fixing mistakes
 
 # %% [markdown]
 # **NOTE:** using bash/git commands is not fully supported on jupyterlite yet (due to single
@@ -31,7 +31,7 @@
 working_dir
 
 # %% [markdown]
-# ### Referring to changes with HEAD and ^
+# ## Referring to changes with HEAD and ^
 #
 # The commit we want to revert to is the one before the latest.
 #
@@ -40,7 +40,7 @@
 # We could use the hash code (e.g. 73fbeaf) to reference this, but you can also refer to the commit before the `HEAD` as `HEAD^`, the one before that as `HEAD^^`, the one before that as `HEAD~3`.
 
 # %% [markdown]
-# ### Reverting
+# ## Reverting
 #  
 # Ok, so now we'd like to undo the nasty commit with the lie about Mount Fictional.
 
@@ -51,7 +51,7 @@
 # An editor may pop up, with some default text which you can accept and save. 
 
 # %% [markdown]
-# ### Conflicted reverts
+# ## Conflicted reverts
 #
 # You may, depending on the changes you've tried to make, get an error message here. 
 #
@@ -60,28 +60,28 @@
 # If that happens, you need to manually edit the file to fix the problem. Skip ahead to the section on resolving conflicts, or ask a demonstrator to help.
 
 # %% [markdown]
-# ### Review of changes
+# ## Review of changes
 #
 # The file should now contain the change to the title, but not the extra line with the lie. Note the log:
 
 # %% jupyter={"outputs_hidden": false} language="bash"
 # git log --date=short
 
 # %% [markdown]
-# ### Antipatch
+# ## Antipatch
 #
 # Notice how the mistake has stayed in the history.
 #
 # There is a new commit which undoes the change: this is colloquially called an "antipatch". 
 # This is nice: you have a record of the full story, including the mistake and its correction.
 
 # %% [markdown]
-# ### Rewriting history
+# ## Rewriting history
 #
 # It is possible, in git, to remove the most recent change altogether, "rewriting history". Let's make another bad change, and see how to do this.
 
 # %% [markdown]
-# ### A new lie
+# ## A new lie
 
 # %% jupyter={"outputs_hidden": false}
 # %%writefile index.md
@@ -106,7 +106,7 @@
 # git log --date=short
 
 # %% [markdown]
-# ### Using reset to rewrite history
+# ## Using reset to rewrite history
 
 # %% attributes={"classes": [" Bash"], "id": ""} jupyter={"outputs_hidden": false} language="bash"
 # git reset HEAD^
@@ -115,12 +115,12 @@
 # git log --date=short
 
 # %% [markdown]
-# ### Covering your tracks
+# ## Covering your tracks
 #
 # The silly spelling *is no longer in the log*. This approach to fixing mistakes, "rewriting history" with `reset`, instead of adding an antipatch with `revert`, is dangerous, and we don't recommend it. But you may want to do it for small silly mistakes, such as to correct a commit message.
 
 # %% [markdown]
-# ### Resetting the working area
+# ## Resetting the working area
 #
 # When `git reset` removes commits, it leaves your working directory unchanged -- so you can keep the work in the bad change if you want. 
 

ch00git/04Publishing.ipynb.py

@@ -12,7 +12,7 @@
 # ---
 
 # %% [markdown]
-# ## Publishing
+# # Publishing
 
 # %% [markdown]
 # **NOTE:** using bash/git commands is not fully supported on jupyterlite yet (due to single
@@ -31,22 +31,22 @@
 working_dir
 
 # %% [markdown]
-# ### Sharing your work
+# ## Sharing your work
 
 # %% [markdown]
 # So far, all our work has been on our own computer. But a big part of the point of version control is keeping your work safe, on remote servers. Another part is making it easy to share your work with the world In this example, we'll be using the "GitHub" cloud repository to store and publish our work. 
 #
 # If you have not done so already, you should create an account on [GitHub](https://github.com/): go to [GitHub's website](https://github.com/), fill in a username and password, and click on "sign up for GitHub". 
 
 # %% [markdown]
-# ### Creating a repository
+# ## Creating a repository
 #
 # Ok, let's create a repository to store our work. Hit "[new repository](https://github.com/new)" on the right of the github home screen.
 #
 # Fill in a short name, and a description. Choose a "public" repository. Don't choose to initialize the repository with a README. That will create a repository with content and we only want a placeholder where to upload what we've created locally.
 
 # %% [markdown]
-# ### Paying for GitHub
+# ## Paying for GitHub
 #
 # For this course, you should use public repositories in your personal account for your example work: it's good to share! GitHub is free for open source, but in general, charges a fee if you want to keep your work private. 
 #
@@ -57,7 +57,7 @@
 # UCL pays for private GitHub repositories for UCL research groups: you can find the service details on the [Advanced Research Computing Centre's website](https://www.ucl.ac.uk/advanced-research-computing/expertise/research-software-development/research-software-development-tools/support-ucl-2).
 
 # %% [markdown]
-# ### Adding a new remote to your repository
+# ## Adding a new remote to your repository
 #
 # Instructions will appear, once you've created the repository, as to how to add this new "remote" server to your repository, in the lower box on the screen. Mine say:
 
@@ -69,7 +69,7 @@
 #       #You should copy the instructions from YOUR repository.
 
 # %% [markdown]
-# ### Remotes
+# ## Remotes
 #
 # The first command sets up the server as a new `remote`, called `origin`. 
 #
@@ -97,7 +97,7 @@
 wsd(message)
 
 # %% [markdown]
-# ### Playing with GitHub
+# ## Playing with GitHub
 #
 # Take a few moments to click around and work your way through the GitHub interface. Try clicking on 'index.md' to see the content of the file: notice how the markdown renders prettily.
 #
@@ -107,7 +107,7 @@
 # ## Working with multiple files
 
 # %% [markdown]
-# ### Some new content
+# ## Some new content
 #
 # So far, we've only worked with one file. Let's add another:
 
@@ -127,7 +127,7 @@
 # cat lakeland.md
 
 # %% [markdown]
-# ### Git will not by default commit your new file
+# ## Git will not by default commit your new file
 
 # %% attributes={"classes": [" Bash"], "id": ""} jupyter={"outputs_hidden": false} magic_args="--no-raise-error" language="bash"
 # git commit -m "Try to add Lakeland"
@@ -136,7 +136,7 @@
 # This didn't do anything, because we've not told git to track the new file yet.
 
 # %% [markdown]
-# ### Tell git about the new file
+# ## Tell git about the new file
 
 # %% attributes={"classes": [" Bash"], "id": ""} jupyter={"outputs_hidden": false} language="bash"
 # git add lakeland.md