Lab Workflow

First, make sure you’ve successfully logged into CLAC and completed the guide on UNIX setup.

You’ll also need to do two more things before you can submit a lab. First, all labs must be completed in a directory named cs3157 in your home directory (~).

You can create it by running:

mkdir --mode=700 ~/cs3157

Next, you should copy over a configuration file for Mutt, a command line email program that the lab submission script will use to email your submission back to you.

cp ~j-hui/cs3157-pub/conf/.muttrc ~/.muttrc

You should only have to complete the above steps once for the entirety of the semester. The following sections will describe various stages of the lab completion workflow for every lab.

Retrieving Skeleton Code

You start <labN> (substitute the current lab number for N) by git-cloning the skeleton code for the lab.

To start <labN>, you will need clone the skeleton repo into your cs3157 repo:

git clone ~j-hui/cs3157-pub/<labN> ~/cs3157/<labN>

You should replace <labN> with the name of the lab you are actually working on. For example, for Lab 1:

git clone ~j-hui/cs3157-pub/lab1 ~/cs3157/lab1

After doing so, you may work on your lab in ~/cs3157/<labN>. As you work on your lab, you should git commit frequently. You must commit at least 5 times before submission.

Note that you should NEVER git init to start your lab assignment. You won’t be able to submit your lab later if you start by running git init. If you’ve done so by accident, please contact the teaching staff for help.

Submitting Your Lab

You should always submit your lab from the root directory of the lab repo, ~/cs3157/<labN>. You should submit using the submit-lab command we’ve installed on CLAC:

submit-lab <labN>

For example, to go to and submit Lab 1:

$ cd ~/cs3157/lab1
$ submit-lab lab1

Our submit script submits your work by creating a patch, which is a text file that describes all the changes that need to be performed to replay your commits on the skeleton repo. Specifically, the submit script will perform the following:

  1. It creates a patch file named <UNI>-<labN>.mbox.
  2. It makes a new clone of the skeleton code in <labN>-<CURRENT-TIME>, and applies your patch into that directory to recreate all your work.
  3. It copies your patch file into the class submission directory.
  4. Lastly, it emails the patch file to you and the class Gmail account.

If all goes well, you will see it printing “SUCCESS!”

At this point, please go into the <labN>-<CURRENT-TIME> submission directory that it just created, and BUILD AND TEST YOUR SUBMISSION. This is what the graders will grade.

I cannot stress enough how important this last building and testing step is. We will only grade what you submit, and if you submit broken code, we will grade broken code. In the past, there have been a number of instances where a student makes a last minute change, submits it, but forgets to thoroughly test it in their submission directory. Please do not make this mistake.

You should practice lab submission well before the deadline. In fact, we recommend that you try submission even before you start working on your code. Add your name, UNI, and other info to the README.txt, commit your changes, and follow the instructions described below to make a practice submission. Make sure everything works and you are comfortable with the submission process. You can submit as many times as you want. Only the last submission counts.

Before your final submission, make sure:

  • You completed your README.txt with all the required information.
  • You have tested your code.
  • You have committed all your changes; you should run git status to check that no source files are untracked or uncommitted.
  • You are have only committed source files and accompanying documentation (i.e., text files). NEVER track binary files such as executables, object files (.o), and library files (.a).

Checking late days

To check how many late days you have left, run the following command on CLAC:


Retrieving the solutions

Lab solutions are published as an additional commit made to the skeleton repo. To retrieve the solutions, you can pull that commit into your repo using Git.

Since the commit history diverges between your commits and mine, you will need to first configure Git to reconcile the divergence by merging my commit (as opposed to rebasing). To configure this behavior, run the following command:

git config --global pull.rebase false

The --global flag configures Git globally rather for each repo, so you only need to run this command once (though it is harmless to run multiple times).

Then, you should use the git pull command to retrieve my lab solutions. For example, to retrieve the Lab 1 solutions:

$ cd ~/cs3157/lab1    # Navigate to your Lab 1 repo
$ git pull            # Pull latest commits from ~j-hui/cs3157-pub/lab1

Running git pull will merge my solutions commit with your own commits. It should open up your text editor, asking for a merge commit message; just save and quit, leaving the default commit message as is (it should say something like Merge branch 'main' of /home/j-hui/cs3157-pub/labN).

After you merge in my commit, you will see a new solutions/ directory in your lab repo containing my solutions.