diff --git a/_freeze/schedule/slides/00-version-control/execute-results/html.json b/_freeze/schedule/slides/00-version-control/execute-results/html.json
index 07067d8..11cda51 100644
--- a/_freeze/schedule/slides/00-version-control/execute-results/html.json
+++ b/_freeze/schedule/slides/00-version-control/execute-results/html.json
@@ -1,8 +1,10 @@
{
- "hash": "4c11482dff7ccd0774726d1457f5ec0d",
+ "hash": "32c50a72dcde2b96f9ea10f126cc1647",
"result": {
- "markdown": "---\nlecture: \"00 Git, Github, and Slack\"\nformat: revealjs\nmetadata-files: \n - _metadata.yml\n---\n---\n---\n\n## {{< meta lecture >}} {.large background-image=\"gfx/smooths.svg\" background-opacity=\"0.3\"}\n\n[Stat 406]{.secondary}\n\n[{{< meta author >}}]{.secondary}\n\nLast modified -- 06 September 2023\n\n\n\n$$\n\\DeclareMathOperator*{\\argmin}{argmin}\n\\DeclareMathOperator*{\\argmax}{argmax}\n\\DeclareMathOperator*{\\minimize}{minimize}\n\\DeclareMathOperator*{\\maximize}{maximize}\n\\DeclareMathOperator*{\\find}{find}\n\\DeclareMathOperator{\\st}{subject\\,\\,to}\n\\newcommand{\\E}{E}\n\\newcommand{\\Expect}[1]{\\E\\left[ #1 \\right]}\n\\newcommand{\\Var}[1]{\\mathrm{Var}\\left[ #1 \\right]}\n\\newcommand{\\Cov}[2]{\\mathrm{Cov}\\left[#1,\\ #2\\right]}\n\\newcommand{\\given}{\\ \\vert\\ }\n\\newcommand{\\X}{\\mathbf{X}}\n\\newcommand{\\x}{\\mathbf{x}}\n\\newcommand{\\y}{\\mathbf{y}}\n\\newcommand{\\P}{\\mathcal{P}}\n\\newcommand{\\R}{\\mathbb{R}}\n$$\n\n\n\n\n\n## Course communication\n\n### Website:\n\n\n\n* Hosted on Github.\n\n* Links to slides and all materials\n\n* Syllabus is there. Be sure to read it.\n\n\n## Course communication\n\n### Slack:\n\n* Link to join on Canvas. This is our discussion board.\n\n* Note that this data is hosted on servers outside of Canada. You may wish to use a pseudonym to protect your privacy.\n\n* Anything super important will be posted to Slack and Canvas. \n\n* Be sure you get Canvas email.\n\n* If I am sick, I will cancel class or arrange a substitute.\n\n## Course communication\n\n### Github organization\n\n* Linked from the website.\n\n* This is where you complete / submit assignments / projects / in-class-work\n\n* This is also hosted on Servers outside Canada \n\n\n\n## Why these?\n\n* Yes, some data is hosted on servers in the US.\n\n* But in the real world, no one uses Canvas / Piazza, so why not learn things they do use?\n\n* Much easier to communicate, \"mark\" or comment on your work\n\n* Much more DS friendly\n\n* Note that MDS uses both of these, the Stat and CS departments use both, many faculty use them, Google / Amazon / Facebook use things like these, etc.\n\n. . .\n\nSlack help from MDS [features](https://ubc-mds.github.io/resources_pages/slack/) and [rules](https://ubc-mds.github.io/resources_pages/slack_asking_for_help/)\n\n# Git and Github\n\n## Why version control?\n\n\n{fig-align=\"center\"}\n\n\n[Much of this lecture is based on material from Colin Rundel and Karl Broman]{.smallest}\n\n\n## Why version control?\n\n* Simple formal system for tracking all changes to a project\n* Time machine for your projects\n + Track blame and/or praise\n + Remove the fear of breaking things\n* Learning curve is steep, but when you need it you [REALLY]{.secondary} need it\n\n::: {.callout-tip icon=false}\n## Words of wisdom\n\nYour closest collaborator is you six months ago, but you don’t reply to emails.\n\n-- _Paul Wilson_\n:::\n\n\n## Why Git\n\n:::: {.columns}\n::: {.column width=\"60%\"}\n* You could use something like Box or Dropbox\n* These are poor-man's version control\n* Git is much more appropriate\n* It works with large groups\n* It's very fast\n* It's much better at fixing mistakes\n* Tech companies use it (so it's in your interest to have some experience)\n:::\n\n::: {.column width=\"40%\"}\n{fig-align=\"center\"}\n:::\n::::\n\n. . .\n\n::: {.callout-important appearance=\"simple\"}\nThis will hurt, but what doesn't kill you, makes you stronger.\n:::\n\n## Overview\n\n* `git` is a command line program that lives on your machine\n* If you want to track changes in a directory, you type `git init`\n* This creates a (hidden) directory called `.git`\n* The `.git` directory contains a history of all changes made to \"versioned\" files\n* This top directory is referred to as a \"repository\" or \"repo\"\n* is a service that hosts a repo remotely and has other features: issues, project boards, pull requests, renders `.ipynb` & `.md`\n* Some IDEs (pycharm, RStudio, VScode) have built in `git`\n* `git`/GitHub is broad and complicated. Here, just what you [need]{.secondary}\n\n## Aside on \"Built-in\" & \"Command line\" {background-color=\"#97D4E9\"}\n\n:::{.callout-tip}\nFirst things first, RStudio and the Terminal\n:::\n\n\n* Command line is the \"old\" type of computing. You type commands at a prompt and the computer \"does stuff\". \n\n* You may not have seen where this is. RStudio has one built in called \"Terminal\"\n\n* The Mac System version is also called \"Terminal\". If you have a Linux machine, this should all be familiar.\n\n* Windows is not great at this.\n\n* To get the most out of Git, you have to use the command line.\n\n\n## Typical workflow {.smaller}\n\n\n1. Download a repo from Github\n```{{bash}}\ngit clone https://github.com/stat550-2021/lecture-slides.git\n```\n2. Create a **branch**\n```{{bash}}\ngit branch \n```\n3. Make changes to your files.\n4. Add your changes to be tracked (\"stage\" them)\n```{{bash}}\ngit add \n```\n5. Commit your changes\n```{{bash}}\ngit commit -m \"Some explanatory message\"\n```\n\n**Repeat 3--5 as needed. Once you're satisfied**\n\n* Push to Github\n```{{bash}}\ngit push\ngit push -u origin \n```\n\n---\n\n{fig-align=\"center\"}\n\n\n## What should be tracked?\n\n \n\nDefinitely\n: code, markdown documentation, tex files, bash scripts/makefiles, ...\n\n \n\nPossibly\n: logs, jupyter notebooks, images (that won’t change), ...\n\n \n\nQuestionable\n: processed data, static pdfs, ...\n\n \n\nDefinitely not\n: full data, continually updated pdfs, other things compiled from source code, ...\n\n\n\n## What things to track\n\n* You decide what is \"versioned\". \n\n* A file called `.gitignore` tells `git` files or types to never track\n\n```{{bash}}\n# History files\n.Rhistory\n.Rapp.history\n\n# Session Data files\n.RData\n\n# User-specific files\n.Ruserdata\n\n# Compiled junk\n*.o\n*.so\n*.DS_Store\n```\n\n* Shortcut to track everything (use carefully):\n\n```{{bash}}\ngit add .\n```\n\n## Rules\n\n### Homework and Labs\n\n* You each have your own repo\n\n* You make a branch\n\n* [DO NOT]{.secondary} rename files\n\n* Make enough commits (3 for labs, 5 for HW).\n\n* Push your changes (at anytime) and make a PR against `main` when done.\n\n* TAs review your work.\n\n* On HW, if you want to revise, make changes in response to feedback and push\nto the same branch. Then \"request review\".\n\n\n## What's a PR?\n\n* This exists on Github (not git)\n* Demonstration\n\n. . .\n\n\n\n## What's a PR?\n\n* This exists on Github (not git)\n* Demonstration\n\n\n\n\n\n## Some things to be aware of\n\n* `master` vs `main`\n* If you think you did something wrong, stop and ask for help\n* There are guardrails in place. But those won't stop a bulldozer.\n* The hardest part is the initial setup. Then, this should all be rinse-and-repeat.\n* This book is great: [Happy Git with R](https://happygitwithr.com)\n 1. See Chapter 6 if you have install problems.\n 1. See Chapter 10 for credential caching (avoid typing a password all the time)\n 1. See Chapter 13 if RStudio can't find `git`\n \n## The `main/develop/branch` workflow\n\n* When working on your own\n 1. Don't NEED branches (but you should use them, really)\n 1. I make a branch if I want to try a modification without breaking what I have.\n \n \n* When working on a large team with production grade software\n 1. `main` is protected, released version of software (maybe renamed to `release`)\n 1. `develop` contains things not yet on `main`, but thoroughly tested\n 1. On a schedule (once a week, once a month) `develop` gets merged to `main`\n 1. You work on a `feature` branch off `develop` to build your new feature\n 1. You do a PR against `develop`. Supervisors review your contributions\n \n. . .\n\nI and many DS/CS/Stat faculty use this workflow with my lab.\n\n## Protection\n\n* Typical for your PR to trigger tests to make sure you don't break things\n\n* Typical for team members or supervisors to review your PR for compliance\n\n\n## Guardrails\n\n* The `.github` directory contains interactions with GitHub\n\n 1. Actions: On push / PR / other GitHub does something on their server (builds a website, runs tests on code)\n 1. PR templates: Little admonitions when you open a PR\n 1. Branch protection: prevent you from doing stuff\n \n* In this course, I protect `main` so that you can't push there\n\n::: {.callout-warning}\nIf you try to push to `main`, it will give an error like\n```{{bash}}\nremote: error: GH006: Protected branch update failed for refs/heads/main.\n```\n\nThe fix is: make a new branch, then push that.\n:::\n\n---\n\n* I also use a PR template. It gives you some instructions that you should follow\n\n\n::: {.callout-important}\nRead the PR template!!\n:::\n\n## Operations in Rstudio \n\n:::: {.columns}\n::: {.column width=\"50%\"}\n\n1. Stage\n1. Commit\n1. Push\n1. Pull\n1. Create a branch\n\n\n::: {.callout-note}\n## Covers:\n* Everything to do your HW / Project if you're careful\n* Plus most other things you \"want to do\"\n:::\n:::\n\n::: {.column width=\"5%\"}\n:::\n\n::: {.column width=\"45%\"}\n\n\n#### Command line versions (of the same)\n\n```{{bash}}\ngit add \n\ngit commit -m \"some useful message\"\n\ngit push\n\ngit pull\n\ngit checkout -b \n```\n\n:::\n::::\n\n## Other useful stuff (but command line only)\n\n:::: {.columns}\n::: {.column width=\"50%\"}\n#### Initializing\n```{{bash}}\ngit config user.name --global \"Daniel J. McDonald\"\ngit config user.email --global \"daniel@stat.ubc.ca\"\ngit config core.editor --global nano \n# or emacs or ... (default is vim)\n```\n\n\n#### Staging\n```{{bash}}\ngit add name/of/file # stage 1 file\ngit add . # stage all\n```\n\n#### Committing\n```{{bash}}\n# stage/commit simultaneously\ngit commit -am \"message\" \n\n# open editor to write long commit message\ngit commit \n```\n\n#### Pushing\n```{{bash}}\n# If branchname doesn't exist\n# on remote, create it and push\ngit push -u origin branchname\n```\n:::\n\n::: {.column width=\"50%\"}\n#### Branching\n```{{bash}}\n# switch to branchname, error if uncommitted changes\ngit checkout branchname \n# switch to a previous commit\ngit checkout aec356\n\n# create a new branch\ngit branch newbranchname\n# create a new branch and check it out\ngit checkout -b newbranchname\n\n# merge changes in branch2 onto branch1\ngit checkout branch1\ngit merge branch2\n\n# grab a file from branch2 and put it on current\ngit checkout branch2 -- name/of/file\n\ngit branch -v # list all branches\n```\n\n#### Check the status\n```{{bash}}\ngit status\ngit remote -v # list remotes\ngit log # show recent commits, msgs\n```\n:::\n::::\n\n## Conflicts\n\n* Sometimes you merge things and \"conflicts\" happen.\n\n* Meaning that changes on one branch would overwrite changes on a different branch.\n\n:::: {.columns}\n::: {.column width=\"50%\"}\n\n* They look like this:\n\n```\nHere are lines that are either unchanged from\nthe common ancestor, or cleanly resolved \nbecause only one side changed.\n\nBut below we have some troubles\n<<<<<<< yours:sample.txt\nConflict resolution is hard;\nlet's go shopping.\n=======\nGit makes conflict resolution easy.\n>>>>>>> theirs:sample.txt\n\nAnd here is another line that is cleanly \nresolved or unmodified.\n```\n\n:::\n\n::: {.column width=\"5%\"}\n:::\n\n::: {.column width=\"45%\"}\n\nYou get to decide, do you want to keep\n\n1. Your changes (above `======`)\n2. Their changes (below `======`)\n3. Both.\n4. Neither.\n\nBut always delete the `<<<<<`, `======`, and `>>>>>` lines.\n\nOnce you're satisfied, committing resolves the conflict.\n\n:::\n::::\n\n## Some other pointers\n\n* Commits have long names: `32b252c854c45d2f8dfda1076078eae8d5d7c81f`\n * If you want to use it, you need \"enough to be unique\": `32b25`\n\n* Online help uses directed graphs in ways different from statistics:\n * In stats, arrows point from cause to effect, forward in time\n * In `git` docs, it's reversed, they point to the thing on which they depend\n \n \n### Cheat sheet\n\n\n\n\n## How to undo in 3 scenarios\n\n* Suppose we're concerned about a file named `README.md`\n* Often, `git status` will give some of these as suggestions\n\n:::: {.columns}\n::: {.column width=\"50%\"}\n### 1. Saved but not staged\n\n* In RStudio, select the file and click ``{=html} ``{=html} then select ``{=html} Revert...\n```{{bash}}\n# grab the previously committed version\ngit checkout -- README.md \n```\n\n### 2. Staged but not committed\n\n* In RStudio, uncheck the box by the file, then use the method above.\n```{{bash}}\n# unstage\ngit reset HEAD README.md\ngit checkout -- README.md\n```\n:::\n\n::: {.column width=\"50%\"}\n\n### 3. Committed\n\n* Not easy to do in RStudio...\n```{{bash}}\n# check the log to see where you made the chg, \ngit log\n# go one step before that (eg to 32b252)\n# and grab that earlier version\ngit checkout 32b252 -- README.md\n```\n\n \n\n```{{bash}}\n# alternatively\n# if it happens to also be on another branch\ngit checkout otherbranch -- README.md\n```\n:::\n::::\n\n## Recovering from things\n\n1. Accidentally did work on main, Tried to Push but got refused\n```{{bash}}\n# make a new branch with everything, but stay on main\ngit branch newbranch\n# find out where to go to\ngit log\n# undo everything after ace2193\ngit reset --hard ace2193\ngit checkout newbranch\n```\n\n2. Made a branch, did lots of work, realized it's trash, and you want to burn it\n```{{bash}}\ngit checkout main\ngit branch -d badbranch\n```\n\n3. Anything more complicated, either post to Slack or LMGTFY\n\n\n\n4. In the Lab next week, you'll practice \n * Doing it right.\n * Recovering from some mistakes.\n \n\n# Example of setting up labs\n\n::: {.notes}\n* Cloning your repo.\n\n* Creating a branch.\n\n* Knitting the Rmd.\n\n* Where to put answers.\n:::\n",
- "supporting": [],
+ "markdown": "---\nlecture: \"00 Git, Github, and Slack\"\nformat: revealjs\nmetadata-files: \n - _metadata.yml\n---\n---\n---\n\n## {{< meta lecture >}} {.large background-image=\"gfx/smooths.svg\" background-opacity=\"0.3\"}\n\n[Stat 406]{.secondary}\n\n[{{< meta author >}}]{.secondary}\n\nLast modified -- 07 September 2023\n\n\n\n$$\n\\DeclareMathOperator*{\\argmin}{argmin}\n\\DeclareMathOperator*{\\argmax}{argmax}\n\\DeclareMathOperator*{\\minimize}{minimize}\n\\DeclareMathOperator*{\\maximize}{maximize}\n\\DeclareMathOperator*{\\find}{find}\n\\DeclareMathOperator{\\st}{subject\\,\\,to}\n\\newcommand{\\E}{E}\n\\newcommand{\\Expect}[1]{\\E\\left[ #1 \\right]}\n\\newcommand{\\Var}[1]{\\mathrm{Var}\\left[ #1 \\right]}\n\\newcommand{\\Cov}[2]{\\mathrm{Cov}\\left[#1,\\ #2\\right]}\n\\newcommand{\\given}{\\ \\vert\\ }\n\\newcommand{\\X}{\\mathbf{X}}\n\\newcommand{\\x}{\\mathbf{x}}\n\\newcommand{\\y}{\\mathbf{y}}\n\\newcommand{\\P}{\\mathcal{P}}\n\\newcommand{\\R}{\\mathbb{R}}\n$$\n\n\n\n\n\n## Course communication\n\n### Website:\n\n\n\n* Hosted on Github.\n\n* Links to slides and all materials\n\n* Syllabus is there. Be sure to read it.\n\n\n## Course communication\n\n### Slack:\n\n* Link to join on Canvas. This is our discussion board.\n\n* Note that this data is hosted on servers outside of Canada. You may wish to use a pseudonym to protect your privacy.\n\n* Anything super important will be posted to Slack and Canvas. \n\n* Be sure you get Canvas email.\n\n* If I am sick, I will cancel class or arrange a substitute.\n\n## Course communication\n\n### Github organization\n\n* Linked from the website.\n\n* This is where you complete / submit assignments / projects / in-class-work\n\n* This is also hosted on Servers outside Canada \n\n\n\n## Why these?\n\n* Yes, some data is hosted on servers in the US.\n\n* But in the real world, no one uses Canvas / Piazza, so why not learn things they do use?\n\n* Much easier to communicate, \"mark\" or comment on your work\n\n* Much more DS friendly\n\n* Note that MDS uses both of these, the Stat and CS departments use both, many faculty use them, Google / Amazon / Facebook use things like these, etc.\n\n. . .\n\nSlack help from MDS [features](https://ubc-mds.github.io/resources_pages/slack/) and [rules](https://ubc-mds.github.io/resources_pages/slack_asking_for_help/)\n\n# Git and Github\n\n## Why version control?\n\n\n{fig-align=\"center\"}\n\n\n[Much of this lecture is based on material from Colin Rundel and Karl Broman]{.smallest}\n\n\n## Why version control?\n\n* Simple formal system for tracking all changes to a project\n* Time machine for your projects\n + Track blame and/or praise\n + Remove the fear of breaking things\n* Learning curve is steep, but when you need it you [REALLY]{.secondary} need it\n\n::: {.callout-tip icon=false}\n## Words of wisdom\n\nYour closest collaborator is you six months ago, but you don’t reply to emails.\n\n-- _Paul Wilson_\n:::\n\n\n## Why Git\n\n:::: {.columns}\n::: {.column width=\"60%\"}\n* You could use something like Box or Dropbox\n* These are poor-man's version control\n* Git is much more appropriate\n* It works with large groups\n* It's very fast\n* It's much better at fixing mistakes\n* Tech companies use it (so it's in your interest to have some experience)\n:::\n\n::: {.column width=\"40%\"}\n{fig-align=\"center\"}\n:::\n::::\n\n. . .\n\n::: {.callout-important appearance=\"simple\"}\nThis will hurt, but what doesn't kill you, makes you stronger.\n:::\n\n## Overview\n\n* `git` is a command line program that lives on your machine\n* If you want to track changes in a directory, you type `git init`\n* This creates a (hidden) directory called `.git`\n* The `.git` directory contains a history of all changes made to \"versioned\" files\n* This top directory is referred to as a \"repository\" or \"repo\"\n* is a service that hosts a repo remotely and has other features: issues, project boards, pull requests, renders `.ipynb` & `.md`\n* Some IDEs (pycharm, RStudio, VScode) have built in `git`\n* `git`/GitHub is broad and complicated. Here, just what you [need]{.secondary}\n\n## Aside on \"Built-in\" & \"Command line\" {background-color=\"#97D4E9\"}\n\n:::{.callout-tip}\nFirst things first, RStudio and the Terminal\n:::\n\n\n* Command line is the \"old\" type of computing. You type commands at a prompt and the computer \"does stuff\". \n\n* You may not have seen where this is. RStudio has one built in called \"Terminal\"\n\n* The Mac System version is also called \"Terminal\". If you have a Linux machine, this should all be familiar.\n\n* Windows is not great at this.\n\n* To get the most out of Git, you have to use the command line.\n\n\n## Typical workflow {.smaller}\n\n\n1. Download a repo from Github\n```{{bash}}\ngit clone https://github.com/stat550-2021/lecture-slides.git\n```\n2. Create a **branch**\n```{{bash}}\ngit branch \n```\n3. Make changes to your files.\n4. Add your changes to be tracked (\"stage\" them)\n```{{bash}}\ngit add \n```\n5. Commit your changes\n```{{bash}}\ngit commit -m \"Some explanatory message\"\n```\n\n**Repeat 3--5 as needed. Once you're satisfied**\n\n* Push to Github\n```{{bash}}\ngit push\ngit push -u origin \n```\n\n---\n\n{fig-align=\"center\"}\n\n\n## What should be tracked?\n\n \n\nDefinitely\n: code, markdown documentation, tex files, bash scripts/makefiles, ...\n\n \n\nPossibly\n: logs, jupyter notebooks, images (that won’t change), ...\n\n \n\nQuestionable\n: processed data, static pdfs, ...\n\n \n\nDefinitely not\n: full data, continually updated pdfs, other things compiled from source code, ...\n\n\n\n## What things to track\n\n* You decide what is \"versioned\". \n\n* A file called `.gitignore` tells `git` files or types to never track\n\n```{{bash}}\n# History files\n.Rhistory\n.Rapp.history\n\n# Session Data files\n.RData\n\n# User-specific files\n.Ruserdata\n\n# Compiled junk\n*.o\n*.so\n*.DS_Store\n```\n\n* Shortcut to track everything (use carefully):\n\n```{{bash}}\ngit add .\n```\n\n## Rules\n\n### Homework and Labs\n\n* You each have your own repo\n\n* You make a branch\n\n* [DO NOT]{.secondary} rename files\n\n* Make enough commits (3 for labs, 5 for HW).\n\n* Push your changes (at anytime) and make a PR against `main` when done.\n\n* TAs review your work.\n\n* On HW, if you want to revise, make changes in response to feedback and push\nto the same branch. Then \"request review\".\n\n\n## What's a PR?\n\n* This exists on Github (not git)\n* Demonstration\n\n. . .\n\n\n\n## What's a PR?\n\n* This exists on Github (not git)\n* Demonstration\n\n\n\n\n\n## Some things to be aware of\n\n* `master` vs `main`\n* If you think you did something wrong, stop and ask for help\n* There are guardrails in place. But those won't stop a bulldozer.\n* The hardest part is the initial setup. Then, this should all be rinse-and-repeat.\n* This book is great: [Happy Git with R](https://happygitwithr.com)\n 1. See Chapter 6 if you have install problems.\n 1. See Chapter 10 for credential caching (avoid typing a password all the time)\n 1. See Chapter 13 if RStudio can't find `git`\n \n## The `main/develop/branch` workflow\n\n* When working on your own\n 1. Don't NEED branches (but you should use them, really)\n 1. I make a branch if I want to try a modification without breaking what I have.\n \n \n* When working on a large team with production grade software\n 1. `main` is protected, released version of software (maybe renamed to `release`)\n 1. `develop` contains things not yet on `main`, but thoroughly tested\n 1. On a schedule (once a week, once a month) `develop` gets merged to `main`\n 1. You work on a `feature` branch off `develop` to build your new feature\n 1. You do a PR against `develop`. Supervisors review your contributions\n \n. . .\n\nI and many DS/CS/Stat faculty use this workflow with my lab.\n\n## Protection\n\n* Typical for your PR to trigger tests to make sure you don't break things\n\n* Typical for team members or supervisors to review your PR for compliance\n\n\n## Guardrails\n\n* The `.github` directory contains interactions with GitHub\n\n 1. Actions: On push / PR / other GitHub does something on their server (builds a website, runs tests on code)\n 1. PR templates: Little admonitions when you open a PR\n 1. Branch protection: prevent you from doing stuff\n \n* In this course, I protect `main` so that you can't push there\n\n::: {.callout-warning}\nIf you try to push to `main`, it will give an error like\n```{{bash}}\nremote: error: GH006: Protected branch update failed for refs/heads/main.\n```\n\nThe fix is: make a new branch, then push that.\n:::\n\n---\n\n* I also use a PR template. It gives you some instructions that you should follow\n\n\n::: {.callout-important}\nRead the PR template!!\n:::\n\n## Operations in Rstudio \n\n:::: {.columns}\n::: {.column width=\"50%\"}\n\n1. Stage\n1. Commit\n1. Push\n1. Pull\n1. Create a branch\n\n\n::: {.callout-note}\n## Covers:\n* Everything to do your HW / Project if you're careful\n* Plus most other things you \"want to do\"\n:::\n:::\n\n::: {.column width=\"5%\"}\n:::\n\n::: {.column width=\"45%\"}\n\n\n#### Command line versions (of the same)\n\n```{{bash}}\ngit add \n\ngit commit -m \"some useful message\"\n\ngit push\n\ngit pull\n\ngit checkout -b \n```\n\n:::\n::::\n\n## Other useful stuff (but command line only)\n\n:::: {.columns}\n::: {.column width=\"50%\"}\n#### Initializing\n```{{bash}}\ngit config user.name --global \"Daniel J. McDonald\"\ngit config user.email --global \"daniel@stat.ubc.ca\"\ngit config core.editor --global nano \n# or emacs or ... (default is vim)\n```\n\n\n#### Staging\n```{{bash}}\ngit add name/of/file # stage 1 file\ngit add . # stage all\n```\n\n#### Committing\n```{{bash}}\n# stage/commit simultaneously\ngit commit -am \"message\" \n\n# open editor to write long commit message\ngit commit \n```\n\n#### Pushing\n```{{bash}}\n# If branchname doesn't exist\n# on remote, create it and push\ngit push -u origin branchname\n```\n:::\n\n::: {.column width=\"50%\"}\n#### Branching\n```{{bash}}\n# switch to branchname, error if uncommitted changes\ngit checkout branchname \n# switch to a previous commit\ngit checkout aec356\n\n# create a new branch\ngit branch newbranchname\n# create a new branch and check it out\ngit checkout -b newbranchname\n\n# merge changes in branch2 onto branch1\ngit checkout branch1\ngit merge branch2\n\n# grab a file from branch2 and put it on current\ngit checkout branch2 -- name/of/file\n\ngit branch -v # list all branches\n```\n\n#### Check the status\n```{{bash}}\ngit status\ngit remote -v # list remotes\ngit log # show recent commits, msgs\n```\n:::\n::::\n\n## Conflicts\n\n* Sometimes you merge things and \"conflicts\" happen.\n\n* Meaning that changes on one branch would overwrite changes on a different branch.\n\n::: flex\n::: w-50\n\n* They look like this:\n\n```\nHere are lines that are either unchanged from\nthe common ancestor, or cleanly resolved \nbecause only one side changed.\n\nBut below we have some troubles\n<<<<<<< yours:sample.txt\nConflict resolution is hard;\nlet's go shopping.\n=======\nGit makes conflict resolution easy.\n>>>>>>> theirs:sample.txt\n\nAnd here is another line that is cleanly \nresolved or unmodified.\n```\n\n:::\n\n::: w-50\n\nYou get to decide, do you want to keep\n\n1. Your changes (above `======`)\n2. Their changes (below `======`)\n3. Both.\n4. Neither.\n\nBut always delete the `<<<<<`, `======`, and `>>>>>` lines.\n\nOnce you're satisfied, committing resolves the conflict.\n\n:::\n:::\n\n## Some other pointers\n\n* Commits have long names: `32b252c854c45d2f8dfda1076078eae8d5d7c81f`\n * If you want to use it, you need \"enough to be unique\": `32b25`\n\n* Online help uses directed graphs in ways different from statistics:\n * In stats, arrows point from cause to effect, forward in time\n * In `git` docs, it's reversed, they point to the thing on which they depend\n \n \n### Cheat sheet\n\n\n\n\n## How to undo in 3 scenarios\n\n* Suppose we're concerned about a file named `README.md`\n* Often, `git status` will give some of these as suggestions\n\n::: flex\n::: w-50\n\n### 1. Saved but not staged\n\n* In RStudio, select the file and click ``{=html} ``{=html} then select ``{=html} Revert...\n```{{bash}}\n# grab the previously committed version\ngit checkout -- README.md \n```\n\n### 2. Staged but not committed\n\n* In RStudio, uncheck the box by the file, then use the method above.\n```{{bash}}\n# unstage\ngit reset HEAD README.md\ngit checkout -- README.md\n```\n:::\n\n::: w-50\n\n### 3. Committed\n\n* Not easy to do in RStudio...\n```{{bash}}\n# check the log to see where you made the chg, \ngit log\n# go one step before that (eg to 32b252)\n# and grab that earlier version\ngit checkout 32b252 -- README.md\n```\n\n \n\n```{{bash}}\n# alternatively\n# if it happens to also be on another branch\ngit checkout otherbranch -- README.md\n```\n:::\n:::\n\n## Recovering from things\n\n1. Accidentally did work on main, Tried to Push but got refused\n```{{bash}}\n# make a new branch with everything, but stay on main\ngit branch newbranch\n# find out where to go to\ngit log\n# undo everything after ace2193\ngit reset --hard ace2193\ngit checkout newbranch\n```\n\n2. Made a branch, did lots of work, realized it's trash, and you want to burn it\n```{{bash}}\ngit checkout main\ngit branch -d badbranch\n```\n\n3. Anything more complicated, either post to Slack or LMGTFY\n\n\n\n4. In the Lab next week, you'll practice \n * Doing it right.\n * Recovering from some mistakes.\n \n\n# Example of setting up labs\n\n::: {.notes}\n* Cloning your repo.\n\n* Creating a branch.\n\n* Knitting the Rmd.\n\n* Where to put answers.\n:::\n",
+ "supporting": [
+ "00-version-control_files"
+ ],
"filters": [
"rmarkdown/pagebreak.lua"
],
diff --git a/schedule/slides/00-version-control.qmd b/schedule/slides/00-version-control.qmd
index 6c0a811..8a08c89 100644
--- a/schedule/slides/00-version-control.qmd
+++ b/schedule/slides/00-version-control.qmd
@@ -43,7 +43,7 @@ metadata-files:
* This is where you complete / submit assignments / projects / in-class-work
-* This is also hosted on Servers outside Canada
+* This is also hosted on Servers outside Canada
@@ -449,8 +449,8 @@ git log # show recent commits, msgs
* Meaning that changes on one branch would overwrite changes on a different branch.
-:::: {.columns}
-::: {.column width="50%"}
+::: flex
+::: w-50
* They look like this:
@@ -473,10 +473,7 @@ resolved or unmodified.
:::
-::: {.column width="5%"}
-:::
-
-::: {.column width="45%"}
+::: w-50
You get to decide, do you want to keep
@@ -490,7 +487,7 @@ But always delete the `<<<<<`, `======`, and `>>>>>` lines.
Once you're satisfied, committing resolves the conflict.
:::
-::::
+:::
## Some other pointers
@@ -512,8 +509,9 @@ Once you're satisfied, committing resolves the conflict.
* Suppose we're concerned about a file named `README.md`
* Often, `git status` will give some of these as suggestions
-:::: {.columns}
-::: {.column width="50%"}
+::: flex
+::: w-50
+
### 1. Saved but not staged
* In RStudio, select the file and click `r fontawesome::fa("gear", fill="blue")` `r fontawesome::fa("caret-down")` then select `r fontawesome::fa("arrow-rotate-left", fill="red")` Revert...
@@ -532,7 +530,7 @@ git checkout -- README.md
```
:::
-::: {.column width="50%"}
+::: w-50
### 3. Committed
@@ -553,7 +551,7 @@ git checkout 32b252 -- README.md
git checkout otherbranch -- README.md
```
:::
-::::
+:::
## Recovering from things