We should add docs about setting up branch protection for live demonstrations:

• Turn on protection for the main branch by checking the following:
  • Require a pull request before merging and its nested bullet Require approvals
  • Do not allow bypassing the above settings
    • This is critical - if this is not turned on and the person doing the demo has repo admin permissions, then the branch protection will not kick in!

In our working with branches demo, we pre-create two branches for parts 3 and 4
https://github.com/AlexsLemonade/2023-chop-training/blob/f28a5e98a6ece0bf5ff07378150874646ddf8f51/instructor-notes/working-with-branches.md?plain=1#L22-L25

The original idea here was to save time, but I don't think this was a particularly important time-saver! Moreover, it makes the examples less realistic. Below I'm proposing updates for how we might modify this live demo in the future. I expect some discussion over this, but I don't think we need to rush to implement these changes until we know if/when we'll be running this workshop again. This issue is mostly to record my immediate thoughts after doing this demo live!

In part 3 of the demo:

• we accidentally work in the wrong branch
• we save the work with git stash
• then we switch into the correct pre-created branch and stash apply

why this merits revisiting

Stashing is great for modified files, but is sort of contrived for brand new files as presented here - we could have just switched into a new branch and the changes would "just be there".

proposed update

• actually make the branch when we need to use it!
• If we want to keep git stash:
  • rather than working on an entirely new script for this part, we might want to modify one of the scripts from part 1 or 2, which would mean using a different issue
• Or, we could actually commit in the wrong branch and git cherry-pick (see next part of issue where I suggest maybe removing cherry pick from part 4!)

In part 4, of the demo:

(edited for syntax)

• we accidentally work in the main branch
• branch protection saves us from pushing
• we then go back to one of those pre-created branches and cherry pick

why this merits revisiting

The only reason we actually cherry pick is because the branch was pre-created! If we created it after making commits incorrectly in main, then we would not need to cherry-pick at all - the commits would just "be there", and we'd only have to go back and git reset --hard the main branch to clean up.

proposed update

• commit in main as before
• make the branch when pushing fails, which can just be pushed right away
• then, just go back and reset main without any need for cherry-picking

but!!

We would still like to teach git stash somehow!
Perhaps it would be good to teach this alongside "taming your PR diff", which is effectively the "stacking" demo. A better motivation for git stash is WIP that you want to save and come back to later, which would be a scenario where you got excited about working on code that is beyond the scope of a given issue.

This repository stores final versions of scripts that will be written as part of live demos. Originally we did not include the final version of the histogram script for the first demo (adding optparse and ggsave), because this will actually be typed out live.
However, upon further consideration, there's no reason not to include here the final version that will be typed out live!

For reference, here it is. Note that 40 bins is being used as the default for 2 reasons:

• This is the number of bins the issue requests.
• To save the instructor from themselves. By making this value the default, the instructor can just hit Source to generate the plot without having to go back and forth running Rscript from the command line.

# Load libraries ---------
library(ggplot2)
library(palmerpenguins)
library(optparse)

# Load input options -------
option_list <- list(
  make_option(
    opt_str = c("--bins"),
    type = "integer",
    default = 40,
    help = "number of bins to use in the histogram"
  )
)
opt <- parse_args(OptionParser(option_list = option_list))
bins <- opt$bins

output_file <- here::here("plots", 
                          glue::glue("penguin_histogram_{bins}_bins.png")
)

# Make histogram of penguin bill depth --------
penguin_histogram <- ggplot(penguins) +
  aes(x = bill_depth_mm) +
  geom_histogram(bins = bins, color = "dodgerblue", fill = "gold") +
  labs(x = "Penguin bill depth (mm)")

# Export plot
ggsave(filename = output_file,
       plot = penguin_histogram)

For the "working with branches" demonstration, two branches should be created ahead of time:
https://github.com/AlexsLemonade/2023-chop-training/blob/8599d075c7c28309e0bea98cdf8e4ff36cf477a4/instructor-notes/working-with-branches.md?plain=1#L22-L25

   * Branch 3 (`<username>/<issue #>-penguins-species-count`): Add script to export TSV of number of each species of penguin to `results/`
     * This branch will have already been created before the workshop, to save time
   * Branch 4 (`git branch <username>/<issue #>-penguins-species-mass`): Add script to export TSV of the mean mass of each penguins species to `results/`
     * This branch will have already been created before the workshop, to save time

We might want to make this happen in the template repo via GHA, but it can't be the same GHA as creates the issues. This is because the branch names should be referencing those issues directly. Therefore, we will want a separate GHA which takes (edit) three inputs:

• First two inputs are the issue numbers these branches will be tackling
• Last input is the username of who will be performing the live demo

We can use this: https://github.com/marketplace/actions/create-branch

Edit: Scope of this issue also involves documenting the overall README to explain this additional setup step!