Setup Seaside

For this assignment, you must use your account on seaside.cs.washington.edu. We will use the CSE systems to evaluate submitted work, and you need to verify that everything you submit works correctly there. See the Setup page from hw0 for more information about how to get started. We recommend that you use Visual Studio Code for this homework.

Setup cse374 on Seaside for changing permissions

You should have cse374 set up from hw1. See the Setup page from hw1 if you need help. Once you have mounted the ~/udrive/cse374 in ~/cse374, just cd ~/cse374 to work in that directory.

Setup Git on Seaside for git operations

Exercise 5 has detailed instructions on how to set up SSH keys to GitLab. Recall that seaside is essentially a load balancer in front of two other machines: cancun(cancun.cs.washington.edu) and calgary(calgary.cs.washington.edu). In that exercise, you should have set up a SSH key on either cancun or calgary already, but probably not both.

You can ssh -T git@gitlab.cs.washington.edu to check whether you are on the machine with SSH key setup. If you see a welcome message, that means you are good to go. If you see a prompt about passwords, that means you need to redo the steps in that exercise to set up another SSH key on the machine.

Clone your own git repo

  1. Open your own repository URL in a web browser. It should be in your GitLab, ending with your own UW NetId. The format should look like “https://gitlab.cs.washington.edu/cse374-23su-students/cse374-23su-UWNetId”.
  2. Look for the “Clone” button on the page. Copy the repository URL. clone button
  3. Go back to your terminal where you have log into seaside. Make sure you are in ~/cse374. Then, run the following command, replacing with your copied repository URL:
git clone git@gitlab.cs.washington.edu:cse374-23su-students/cse374-23su-UWNetId.git
  1. Git will download the repository to your seaside machine. You now have a local copy of your repository.

  2. Change directory to the local copy of your repository:

cd cse374-23su-UWNetId

Caution

If you get an error saying “Permission denied (publickey)…”, then there is a problem with your GitLab configuration. Check to make sure you have your SSH key setup correctly, your private key is in your SSH directory (~/.ssh), and that you can view the repository through the website.

Set cse374-23su-hw repo as an upstream remote

Once you clone the empty reposity onto your machine you’ll run a couple of commands to get the actual files (and upload it!):

git remote add upstream git@gitlab.cs.washington.edu:cse374-23su-students/cse374-23su-hw.git

Git will add the cse374-23su-hw repository as an upstream remote to your repository.

The copy on your file system is a local copy, and the copy on GitLab is referred to as the origin remote copy. You can view a list of these remote links as follows:

git remote -v

See the documentation for more details on working with remotes – they can be confusing!

For reference, your final remote configuration should read like the following when it’s setup correctly (run git remote -v):

origin  git@gitlab.cs.washington.edu:cse374-23su-students/cse374-23su-UWNetId.git (fetch)
origin  git@gitlab.cs.washington.edu:cse374-23su-students/cse374-23su-UWNetId.git (push)
upstream        git@gitlab.cs.washington.edu:cse374-23su-students/cse374-23su-hw.git (fetch)
upstream        git@gitlab.cs.washington.edu:cse374-23su-students/cse374-23su-hw.git (push)

In this configuration, the origin (default) remote links to your repository where you’ll be pushing your individual submission. The upstream remote points to our repository where you’ll be pulling subsequent homework and bug fixes (more on this below).

Pull starter code from the upstream repo

You will need to pull updates from the cse374-23su-hw repository to get the actual files for hw3, and then upload it.

git pull upstream main
git push

In the future, we will be releasing homework to the repository that you just added as an upstream remote. If you have made any changes to your own repository, commit them before proceeding to the git pull. Otherwise, the merge step might fail.

When you pull the code, Git may open a text editor to allow you to specify a merge commit message; you may leave this as the default. Note that these changes are merged locally, but we will eventually want to push them to the GitLab repository (git push).

Note

It’s possible that there aren’t any pending changes in the upstream repository for you to pull. If so, git will tell you that everything is up to date.

🎉 Congratulations! You have successfully set the cse374-23su-hw repository as an upstream remote and pulled starter code from it into your own repository. Spend a few minutes getting familiar with the directory layout and file structure. Then, you can cd hw3 and start working on hw3!

Tip

Commit early and often! Any time you commit and push your local changes, they will appear in the GitLab repository. Since you’ll be submitting the homework to Gradescope via the GitLab repository, it’s important that you remember to push all of your changes!

(Optional) Test out the origin remote

Let’s test out the origin remote by doing a push of your main branch to GitLab. Do this by issuing the following commands in the git repo:

touch empty_file
git add empty_file
git commit empty_file -m "Testing git with an empty file"
git push # ... to origin by default

The git push tells git to push all of your committed changes to a remote. If none is specified, origin is assumed by default (you can be explicit about this by executing git push origin). Since the upstream remote is read-only, you’ll only be able to pull from it.

After executing these commands, you should see something like the following:

Enumerating objects: 4, done.
Counting objects: 100% (4/4), done.
Delta compression using up to 32 threads
Compressing objects: 100% (2/2), done.
Writing objects: 100% (3/3), 315 bytes | 45.00 KiB/s, done.
Total 3 (delta 0), reused 0 (delta 0), pack-reused 0
To gitlab.cs.washington.edu:cse374-23su-students/cse374-23su-UWNetId.git
   5c12e02..e2aa7f7  master -> master

We pushed a blank file to our origin remote, which isn’t very interesting. Let’s clean up after ourselves:

# Tell git we want to remove this file from our repository
git rm empty_file
# Now commit all pending changes (-a) with the specified message (-m)
git commit -am "Removed test file"
# Now, push this change to GitLab
git push

If you don’t know Git that well, this probably seemed very arcane. Just keep using Git and you’ll understand more and more.