COMS 3157 Advanced Programming

Lab Workflow

1. Preparation

The following steps must be performed once in the beginning of the semester to setup your environment.

(a) Learn Git and set up your Git configuration

First, you must go through the Git tutorial to learn the basics of Git.

Make sure you have configured your git environment by issuing the following commands while logged into CLAC:

git config --global user.name "Your Full Name"
git config --global user.email your_uni@columbia/barnard.edu

Verify your configuration by typing git config -l

(b) Create `~/cs3157` directory

Create cs3157 directory under your home directory and set the permissions to 700:

cd
mkdir cs3157
chmod 700 cs3157

All your labs will be done inside this directory, and chmod 700 ensures that other people cannot see what’s in the directory.

(c) Setup command line email configuration

Execute the following commands:

cd
cp /home/jae/cs3157-pub/conf/.muttrc ./

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

2. Retrieving skeleton code

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

Go into cs3157 directory and git clone labN from /home/jae/cs3157-pub directory:

cd cs3157
git clone /home/jae/cs3157-pub/labN labN

Your job is to modify existing files (rename or remove them if necessary) and add new files to complete the lab.

IMPORTANT: Note that you do NOT git init to start your lab assignment. You won’t be able to submit your lab later if you start by running git init.

As you work on your lab, you should git commit frequently. You are required to git commit at least 5 times before submission.

3. Submitting your lab

First of all, please practice lab submission well before the deadline. In fact, I recommend that you try submission even before you start working on your code. Make some trivial changes to the skeleton code, git commit, and follow the rest of this section to submit your change. 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 you submit your finished work, make sure:

You wrote README.txt, containing all the info that you were required to include.
You have tested your code.
You have committed all your changes. Run the following commands in each part’s directory:

make clean
git status

Make sure that there is no source file that is untracked or uncommitted. Make sure that nothing other than source files and documentations are tracked. Do NOT track binary files such as executables, object files, and library files.

Submit your work by running the submit-lab script:

/home/w3157/submit/submit-lab labN

The submit script will perform 4 steps to submit your lab:

It creates a patch file named YOUR_UNI-labN.mbox.
It makes a new clone of the skeleton code into labN-CURRENT_TIME directory, and applies your patch into that directory to recreate all your work.
It then copies your patch file into the class submission directory.
Lastly, it emails the patch file to the class Gmail account.

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

At this point, please go into the labN-CURRENT_TIME directory that it just created, and build and test your code. This is what the graders will grade. I cannot stress enough how important this last build & testing step is. There have been a number of instances where a student makes a last minute change in his/her code or Makefile, submit it, but forgot to test it afterwards. Unfortunately, the student made a typo while making the last minute change, which made the build to fail. Everyone received ZERO in those cases, absolutely no exception.

4. 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.

From the point when you cloned the skeleton repo to start working on your lab, the commit histories of the skeleton repo and your repo went two different ways: you worked on your lab and I added the solutions. In Git parlance, the commit history diverged.

Before you can pull my solution commit into your repo, you need to tell Git how you would like to reconcile the divergence. There are two choices: merging vs. rebasing. Choose merging by running 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 for all the labs (though it is harmless to run multiple times). If you are curious about the difference between merging and rebasing, read the Yet Another Git Guide by John Hui, an excellent exposition of the often illusive concepts of commits, branches, merging and rebasing.

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

$ cd ~/cs3157/lab1
$ git pull

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 …”).

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