CS61C $ummer 2017 Lab 0 - git and Number Representation


Reading (related, not required, but recommended!)

Policies and Partners

You are REQUIRED to have a partner for lab checkoffs. Sorry if this isn't something you're used to! Working with a partner is a valuable and nontrivial skill that we want you to practice. It will reduce the number of check-offs we have to perform (allowing us to answer more of your questions) as well as give you someone to discuss class material with. Plus, if you find a great partner early in the class (AKA now), you can easily reach each other to work on other stuff later on! :)))) BOTH partners will need to be present at check-off to receive credit and both partners will be asked to participate during the check-off.

How Checkoffs Work

You'll notice that at the end of (almost) every exercise, there is a section labelled "Check-off" in a beige-tinted box. The tasks in this section are what you must successfully complete and show to your TA/Lab assistant/Tutor in order to receive credit for completing the lab. Once you and your partner finish ALL of the exercises, you should put your names and logins on the checkoff queue on the board, and wait for a staff member to check you off. PLEASE use this queue only for checkoffs when you are COMPLETELY done! If you have a question or are unsure of anything, use the question queue instead.

Labs in CS61C are graded out of 2 points. A lab is considered on-time if it is turned in within the first hour of the NEXT LAB SESSION. For example, the lab assigned to you in this week's lab is this document, lab 0. Thus, the latest you may get lab 0 checked off for full credit is the first hour of your lab on Thursday the 21st. Each week that the lab is late past this point, you lose one point on the lab.

Note: There are only 12 labs in total, but your total lab score is out of 30 course points, of which there are 300 in total. So one lab is actually worth 2.5 course points, despite it being graded out of 2 points.


In today's lab only, you should do exercises zero through three alone. You will need a partner for exercises four and five.

Exercise 0: Account and Environment Setup

To obtain your CS61C login, go to https://acropolis.cs.berkeley.edu/~account/webacct/ and login using your Calnet ID. Once you login, create a new account for CS61C. This should give you a username and a temporary password. Once you login, you should change your password. In terminal, enter ssh cs61c-xxx@update.cs.berkeley.edu replacing xxx with your three-letter login and follow the prompts.

Now you're ready to start the lab (finally)! The rest of the lab assumes that you remain logged into your class account.


HEY! Are you about to ask to be checked off? STOP!! Only request to be checked off once you've finished the WHOLE lab! Thanks!

Exercise 1: Bitbucket Account Setup

Please read the following instructions carefully before proceeding. Almost all issues students run into during this lab can be prevented by carefully following the steps provided. Even if you have experience with git from previous 61 series classes, the process we use to set up your accounts may be different in this class.

This semester, we will be requiring that you use git, a distributed version control system. Version control systems are better tools for sharing code than emailing files, using flash drives, or even other file sharing mechanisms like Dropbox.

We'll be using Bitbucket to host private repositories in which you'll store your code. If the previous sentence means nothing to you, don't be alarmed! We'll walk through the process shortly. But first, you'll need to create a Bitbucket account if you don't already have one.

Why Bitbucket? Bitbucket allows accounts to have unlimited private repos. GitHub limits this to 5 per (student) user. Since many of you have already used those 5, we decided to use Bitbucket. If you have experience using Github.com in previous classes, don't worry: Bitbucket interacts with git in the same way as Github.com, it is just a different website for hosting the remote (online) repositories.

Setting up Bitbucket and creating a Bitbucket repository

Navigate to bitbucket.org

Setting up git

Now that we have created our repo, lets configure git so that it knows who you are. Run the commands listed below, replacing YOUR NAME with your first and last name (inside quotes) and YOUR EMAIL ADDRESS with the email address you used to register for your Bitbucket account:

$ git config --global user.name "YOUR NAME"
$ git config --global user.email "YOUR EMAIL ADDRESS"

This is intended to be done on an instructional machine, with you logged into your instructional account. However, this should be done anywhere you intend to push+pull stuff from your BitBucket (AKA anywhere you intend to work on projects), so you may want to do it on your own laptop as well.


Exercise 2: Learn git

Visit try.github.com to work through a quick hands-on introduction to git. Here, you'll work on a "simulated" repository, so that you get some experience before you create your actual coursework repository. Don't worry if you don't feel like an expert after this tutorial - git is a complicated program, so we'll be incorporating it into upcoming assignments to help you familiarize yourself with its intricacies. At least one of your TAs is just as lost as you are about git...heh.


Exercise 3: Create your git repository for CS61C

Since we've already done a whirlwind tour of git in the last exercise, let's jump right in and create a local repository to house our coursework for CS61C:

First, we'll make a directory that represents the highest-level ("root") directory in our git repository. We'll call this directory "work", place it in the home directory of our class account, and enter into the directory:

$ mkdir ~/work
$ cd ~/work

Next, we'll run git init, which will place our ~/work directory under version control.

$ git init

As in the last exercise, this will create a directory inside ~/work called .git/. This is where git stores all of the information about your repository.

We won't need to work with any files for the number-representation part of this lab, so let's create a dummy README file to put under version control:

$ echo "Hello World! This is cs61c-XX's repository." > README

Now, type git status. You should get output like the following:

On branch master

Initial commit

Untracked files:
  (use "git add <file>..." to include in what will be committed)


nothing added to commit but untracked files present (use "git add" to track)

Here, git is telling us that we have a file named README that is not tracked as part of the repository.

In order to place the file under version control, let's use git add to stage the README file to be committed. Since README is a new file, we're telling git to begin tracking changes to the file. Essentially, by using the git add command, we are telling git which changes we want added to the repository when we next type git commit. A commit is basically a snapshot of all of the files in your repository at some point in time.

[tell git to start tracking the README file:]
$ git add README

Now, if you type git status once again, you'll see output like the following:

On branch master

Initial commit

Changes to be committed:
  (use "git rm --cached <file>..." to unstage)

        new file:   README

This output indicates that we've now staged the README file to be committed to the repo next time we type git commit.

Now, we will actually make a commit using git commit. This command will take a commit message, which will allow us to easily identify what was added or changed in the repo at this point in time.

$ git commit -m 'First Commit! - Added new README file'

Side note: if you commit without entering a commit message, git will complain and take you to a text editor, requesting a commit message. It's always a good idea to include a commit message, even if it's short (and possibly angry).

Now, if you once again type git status, you'll see output like the following:

On branch master
nothing to commit, working directory clean

This is exactly what we wanted. Since we just made a commit, the files in the directory and the versions of them known to git are the same. Thus, git reports that the current working directory (~/work) is clean.

Now, if you type git log, you should see the commit history of your repository:

$ git log
commit 160694f5e5a229a12c82262511756cef1d0714c0
Author: David Adams <dadams@berkeley.edu>
Date:   Thu Jan 22 14:33:41 2015 -0800

    First Commit! - Added new README file

Once you make more commits, the output of git log will show you information about the most recent commits in the repository.

As it stands, there are two problems with our local repository:

  1. We don't have a backup copy. You should always backup your code!
  2. Our local copy is private only to us. What if we want to share our code with our project partner?

We will resolve both of these issues by using Bitbucket. Bitbucket will store a "remote" copy of our repository. This serves both as a backup that we can re-clone if we accidentally destroy our local copy and allows us to share the contents of the repository with other Bitbucket users if we'd like.

Currently, we only have a single local copy of our repository. Let's go ahead and push to our private repository on Bitbucket. In order to do so, we'll need to add a "remote", which points to our space on Bitbucket. You should replace cs61c-xxx in the command below with your login:

[ in the command below, you MUST replace cs61c-xxx with your login, and both ]
[     instances of <username> with your Bitbucket username                  ]

$ git remote add origin https://<username>@bitbucket.org/<username>/cs61c-xxx

Now let's tell git to send the contents of our repository to Bitbucket. We do this with the git push command, specifying where we want to send the code (to "origin", which we defined above) and the branch ("master"). We will cover branches in more detail later on.

$ git push -u origin master

Now, let's head to the Bitbucket website and click on the repo name (your class account login). Alternatively, you can go directly to https://bitbucket.org/<username>/cs61c-xxx, replacing xxx with the three letters at the end of your class account login.

Woo! Notice how our README file is now uploaded to the copy of the repository on Bitbucket. Anything that you commit to the repository and then push will be stored on Bitbucket in addition to your local copy of the repository.

As we do more work in this course, you should create subdirectories in this repository to place your projects. The general workflow you'll use will adhere to the following format:

$ cd ~/work
$ mkdir assignment_name
$ [copy assignment files into the assignment_name directory as instructed by the assignment]
$ git add assignment_name/
$ git commit -m 'adding skeleton for assignment_name'
$ git push origin master
$ [work on assignment, modifying files in the ~/work/assignment_name directory]
$ git add -u # the -u tells git to stage changes to all known files - aka skeleton files you filled in 
$ git commit -m "completed question 1 in assignment_name"
$ git push origin master
$ [go back to "work on assignment step," repeat until done assignment]

At this point, we've covered enough of the basics of git to make it useful as a code backup system. In a later lab, we'll discuss more about how to use git as a collaborative tool. We'll explore topics like branching, merging, and pulling.


Exercise 4: Binary Alphabet

At this point, you should begin to work with a partner.

Let's take a look at some 4-bit numbers. If we stack five 4-bit numbers on top of each other in binary, we can make patterns and pictures! To help visualize this, you can think of 0's and 1's as white and black instead. For example, what does the following bit pattern look like?

0 1 1 0   ■ ■ □
1 0 0 1   □ □ ■
1 1 1 1 -->   ■ ■ ■
1 0 0 1   □ □ ■
1 0 0 1   □ □ ■

Does this seem silly and random to you? That's okay: the idea is just for you to practice converting bit patterns (The alphabet letters) into binary numbers and then into base 10 and base 16, which will be very helpful later on! If this feels easy to you, you could maybe share your tips and tricks with your partner. Good communication skills are also important to practice :)


Exercise 5: 1,000 $1 Bills

I hand you a thousand $1 bills and ten envelopes. Your job is to find a way to put various numbers of dollar bills in those ten envelopes so that no matter what amount of money I ask you for (between $1-1000), you can simply hand me some combination of envelopes and always be assured of giving me the correct amount of cash.


Hint: If you're confused about what to put in each envelope, think about how binary numbers work for some inspiration :)