CSCI 162 Lab 1:

Git for lab distribution/collection,
Basic linux/bash,
Binary, octal, hexadecimal representation of integers

Schedule:

In the labs of week 2 (Jan. 16) we'll introduce the git submit process and review some basic linux/bash commands.

The labs of week 3 (Jan. 23) we'll briefly recap the two's complement representations and operations we covered in the lectures.

The lab exercise is due at 5pm on Tuesday January 29th.

Reference material:

Lab exercises:

Part 0: login to your csci account and set up a csci 162 directory

Open a command (terminal) window on the csci server (either using ssh or putty from your laptop, or using Applications -> System Tools -> MateTerminal on one of the lab workstations, and login to your csci account.

If you have taken this course previously, and you have a directory with your old 162 work, rename it to ensure your old work doesn't get confused with this year's work, e.g. to rename csci162 to old162:
mv csci162 old162

Create a directory for your csci 162 material, and cd into that directory:
mkdir csci162
cd csci162

Part 1: fork, clone, and try a first push of this week's lab

You will follow this same process to obtain the collection of code for every lab this semester, just replacing lab1 in the instructions with lab2, lab3, etc.

At some point before the labs begin each week, on the csci git server the instructor will create the code/readme/files to be used for the lab, putting them all in a directory that has been configured for use with git (we'll refer to these directories as git repositories).

AFTER the instructor has done that, you'll be able to begin the steps below.

  1. Check that you're in your csci162 directory, then to create your own copy of the git repository on the central git server enter the following command exactly as shown:
    ssh csci fork csci162/lab1 csci162/$USER/lab1
    If you see a warning about "x11" you can safely ignore that (or use "ssh -x" in the future instead of just "ssh"), if you see any other kind of error then your attempt may have failed, ususally due to entering the command incorrectly.

  2. Since you can't login to the central git server directly (you can just send specific supported commands to it using ssh), we'll make a copy of the repository here in your csci162 directory. Enter the following command exactly as shown:
    git clone csci:csci162/$USER/lab1
    If this succeeded, there should now be a lab1 directory inside your csci162 directory. You can check this using the command
    ls -a lab1
    If everything has been done correctly so far, this should show a README file, an answers.txt file, and a .git directory.
    If the answers.txt file is missing then you'll need to go through some steps to clean up and start over. The cleanup steps are given in the table below.
    If your answers.txt file is missing: you most likely either
      (a) tried to fork before the instructor released the material,
      (b) forgot to fork before cloning, or
      (c) made a mistake in the fork command but did the clone anyway.

    You can try the following fix:

    1. Remove the local directory, e.g.
      rm -r lab1
    2. Move the mistakenly forked central repository to the trash repository, e.g.
      ssh csci D trash csci162/$USER/lab1
    3. Go back to Part 1 of the lab and start again.

  3. Once you have successfully created your local (a.k.a. working) copy, let's try modifying it, updating the git tracking system to include your modifications, and "push" your changes back to the central server (where the instructor is able to access them).

    Change directory into your lab1 (i.e. cd lab1) and then use your preferred editor to edit the answers.txt file. You'll see the file just has one line, saying "Put your name here". Replace that line with your name, save the file, and exit the editor.

    We can see what git is keeping track of with the following command:
    git status
    If you run that command now, it should tell you there are untracked changes in file answers.txt.

    To tell git that you want it to keep track of your latest changes, we tell it which file changes we want to make note of:
    git add answers.txt
    If we have created/altered multiple files, we could instead use a shorthand (essentially telling it to keep track of all the changes we just made), using
    git add .
    If we run the git status command again, we'll see that answers.txt is no longer "untracked", but now it tells us there are "changes to be committed".

    To commit our changes, we use git commit along with a message describing the changes, e.g.
    git commit -m "Add my name to answers.txt"
    (If we forget the -m and the message, git will open a default editor window and expect us to type in the description of the changes then save the file.)
    After performing the commit, if we run git status one more time it should tell us there is nothing to commit and the working tree is clean, but will also tell use our branch is ahead of origin/master by 1 commit, meaning we have made local changes that we haven't yet copied back to our repository on the git server.

    Now, to save our changes back to the central repository (so the instructor can access them) use the command
    git push

    If we try git status after the push, we should see our branch is up-to-date with 'origin/master'.

Part 2: bash/linux exercise For this part, using whichever editor you prefer, put your answers in file answers.txt in your lab1 repository.

The questions for part 2 are in the README file in your repository, use the following command to view the README contents:
less README
(Type q to quit/get out of less.)

Once you have completed the steps above (and saved the file), be sure to add, commit, and push your updates like we did in Part 1:

Part 3: number representation exercise

As with part 2, the actual questions are in the README, and you should use your preferred editor to put your answers in file answers.txt.

Once you have done that (and saved the file), be sure to add, commit, and push your updates like we did earlier:

REMEMBER: if you miss the add, the commit, or the push then your changes never make it back to the central repository, so they'll never get marked!