Infrastructure

This handout covers the basics of using Git for labs, plus editor suggestions for working on lab machines over SSH.

Code editors

Most of the labs in this course are completed on the lab machines, which you will connect to through SSH. Therefore, we recommend using a code editor that supports remote editing over SSH. While there is a bit of a learning curve, we recommend Vim as it provides a better editing experience than nano.

We disallow using VS Code remote edit on lab machines (especially for Cache Attacks, Rowhammer, and Spectre labs). Certain labs have fragile setups when it comes to cache states and other microarchitectural resources, which you will share with dozens of other students. In order to prevent interference with other students’ experiments, we do not allow remote editing on these labs.

Vim

Vim is a good default choice for editing directly on lab machines (it’s more capable than nano, but has a learning curve).

• Learn basics: run vimtutor
• Show line numbers: add the following line to ~/.vimrc on the machine you’re using:

set number

Git

We use Git for retrieving starter code and submitting the code portion of labs. We also recommend using Git throughout the lab to keep checkpoints you can return to later.

Setup

• Install Git: Follow the official instructions at https://git-scm.com/book/en/v2/Getting-Started-Installing-Git.
• GitHub access / SSH keys: Follow the same steps described in the Labs page under “Submission Instructions → GitHub” (or see the upstream reference here).

Using Git

For this class, the main Git tasks are cloning the repository, committing your work locally, and pushing to GitHub.

Clone

git clone git@github.com:<YOUR_USERNAME>/<YOUR_REPOSITORY>.git

If you are using GitHub Classroom, replace the above with the repository link provided by the course staff (see the Labs submission instructions).

Stage changes (git add)

Stage modified files so they are included in the next commit:

git add <MODIFIED_FILES>

We recommend staging everything when you’re ready to checkpoint:

git add .

This prevents accidentally forgetting to add files that have been changed.

Create a snapshot (git commit)

Create a commit to checkpoint your current state:

git commit -m "describe what you changed"

The git commit command snapshots the state of your code, and the commit message provides a way to tag the snapshot. We recommend committing frequently with descriptive commit messages to allow for easy rollbacks and a record of your code to help with your own lab progress.

Submit (git push)

Push your local commits to GitHub:

git push

We can only grade what is in your remote repository. Make sure you push before the deadline.

Typical workflow

git clone <REPO_LINK>   # clone the lab initially
cd <REPO_DIR>           # navigate to the repository directory

# edit files...

git add .                     # stage all changes
git commit -m "finish part A" # create a snapshot of your code
git push                      # push your changes for submission