UNB/ CS/ David Bremner/ tags/ git

This feed contains pages with tag "git".

Before the lab

  • Complete the On your own part of L02


Questions from last time

10 Minutes
Group discussion

In this part of the lab, we will discuss some questions from the On your own part of L02.



The DrRacket stepper

20 min
Individual work

Unit testing is an important part of programming, and has inspired something called test driven development.

This part is based on an example from RackUnit QuickStart. - copy arith.rkt, save it as ~/cs2613/labs/L03/arith.rkt and commit it.


20 min
Small Groups
new evaluation rules for and and or

As you read in FICS unit 3, we can understand evaluation ("running") of Racket programs as a sequence of "reductions" or "substitutions". These rules are similar to the reduction steps in the DrRacket stepper.

The stepper uses the following rules for and and or (notice that these rules enforce short circuit evaluation)

(and true exp2 ...) => (and exp2 ...)
(and false exp2 ...) => false
(or true exp2 ...) => true
(or false exp2 ...) => (or exp2 ...)
(and) => true
(or) => false

Following Exercise 7, write a new set of rules that requires at least two arguments for and and or. The rules are for human consumption; you can write them as comments in DrRacket. You can write "exp1 exp2 ..." to mean at least 2 expressions.

Discuss your answers with a your group, and try a couple evaluation small examples by hand using your rules.

Test Coverage

25 min
Individual work

If you have extra time

Reading for next lab

On your own

20 min
Independent research

See if you can come up with answers to the following questions for next time.

Posted Wed 13 Sep 2023 08:30:00 AM Tags: /tags/git
Lab 2

Before the lab


Git Tutorial Continued

Making Changes in git

20 minutes
Individual work
Get some practice commiting your changes to git.

Having at look at our test post from Lab 1, we can observe the post template adds a bunch of stuff related to social media. Let's suppose that for our cs2613 journal we want a more minimal look.

Start by finding the right files to edit with

$ git grep disqus

git grep is a very useful (and fast!) tool to find occurrences of strings in your git repository. Notice in the output there are some files created by frog; we will clean those up later. Find the template file (under _src) and edit it to remove the undesired social media links. Check the results with

$ raco frog -bp

You might notice one more link to twitter in a different template file. Feel free to remove that one as well.

Use git add to stage your changes:

$ git add file1 file2 file3

You are now ready to commit. You can see what is about to be committed using git diff with the --cached option:

$ git diff --cached

(Without --cached, git diff will show you any changes that you’ve made but not yet added to the index.) You can also get a brief summary of the situation with git status:

$ git status
# On branch master
# Changes to be committed:
#   (use "git reset HEAD <file>..." to unstage)
#       modified:   file1
#       modified:   file2
#       modified:   file3

It’s a good idea to begin the commit message with a single short (less than 50 character) line summarizing the change, followed by a blank line and then a more thorough description. The text up to the first blank line in a commit message is treated as the commit title, and that title is used throughout Git.

If you need to make any further adjustments, do so now, and then add any newly modified content to the index. Finally, commit your changes with:

$ git commit

This will again prompt you for a message describing the change, and then record a new version of the project.

Alternatively, instead of running git add beforehand, you can use

$ git commit -a

which will automatically notice any modified (but not new) files, add them to the index, and commit, all in one step. Keep in mind that you will be marked on the logical structure of your git commits, so you are better off using git add to explicitely choose what changes to commit.

Cleaning up generated files

15 minutes
Individual work
Get some practice commiting your changes to git.

A common phenomenon in software development is the existence of generated files. These files are created by some tool, typically based on some source files. In general it is a bad idea to track generated files in version control because they introduce spurious changes into history. We'll look at this more later, but for now let's try to clean up. We can find out what files are generated .e.g. by consulting the frog docs. Let's first try a shortcut. Run

$ cd ~/cs2613/journal
$ raco frog --clean

To find out what changed, run

$ git diff --stat

All going well, you will see a bunch of deletions. We can tell git to make those deletions permanent in several ways. It turns out that there is a handy option to git add that tells git to stage all of the changes in the working tree. Try to figure out which option it is.

When you are satisfied with the changes, run git commit.

It will turn out that this is not all of the generated files; we can use git rm to clean up further as we find more.

Make sure you run

$ raco frog -bp

To make sure the the blog still works after your deletions.

Viewing project history

15 minutes
Small group discussion, presenting work to the group, peer feedback
Reinforce idea of commit message quality
  1. At any point you can view the history of your changes using

     $ git log

    Use this command to verify that all the changes you expected to be pushed to the server really were.

    If you also want to see complete diffs at each step, use

     $ git log -p

    Often the overview of the changes is useful to get a feel for each step

     $ git log --stat --summary
  2. In most projects, you have to share commit messages to (at least) the same people who view your source code. Share your "best commit" message with one or more of your neighbours.

  3. Find something positive to say about the other commit messages you are reading.

  4. Find a constructive improvement with one of the other messages. Don't be mean, people have varying levels of experience with this.

Geting started with racket

Hello Racket World

15 Minutes
Group walkthrough
#lang htdp/bsl
"hello world"
(* 6 7)

Command Line

DrRacket: A Racket Specific IDE

Racket Expressions.

20 minutes
Small groups
#lang htdp/bsl
(define y 18)
(define (t1 x)
  (or (= x 0) (< 0 (/ y x))))
(define (t2 x)
  (or (< 0 (/ y x)) (= x 0)))
(define (t3 x)
  (and (= x 0) (< 0 (/ y x))))
(define (t4 x)
  (or (< 0 (/ y x)) (not (= x 0))))

Racket functions

20 minutes
Individual work
(check-expect (middle-of-three 1 2 3) 2)
(check-expect (middle-of-three 2 1 3) 2)
(check-expect (middle-of-three 1 3 2) 2)

Before Next Lab

On your own

In this part of the lab I will give some activities that you should work through on your own after the scheduled lab time. These will be copied to the "Before the lab" section of L03.

Working with multiple git repos

15-30 minutes
Individual work, outside scheduled lab time.


  1. Open a terminal.

  2. Make a directory lab2-scratch somewhere outside the cs2613 git repository you created earlier.

  3. Now move to the lab2-scratch directory, and make a clone of the central repo.

     $ git clone https://$username@vcs.cs.unb.ca/git/cs2613-$username cs2613-clone

    This creates a new directory "cs2613-clone" containing a clone of your repository. Notice that in general this is a good way of checking that your work is properly submitted. The TA and Prof will do exactly this cloning step in order to mark your work. The clone is on an equal footing with the original project, possessing its own copy of the original project’s history.

Sharing changes with a central repo

Optional, but useful if you plan to run git on your own computer

  1. Open a terminal

  2. Navigate to the ~/lab2-scratch/cs2613-clone/journal directory.

  3. create a new blog entry, and commit it.

  4. Push your changes back to the central repository.

     $ git push origin master
  5. Change directory to your original directory ~/cs2613. Bring in the changes you made

     $ git pull origin

This merges the changes from the central copy of "master" branch into the current branch. If you made other changes in the meantime, then you may need to manually fix any conflicts.

The "pull" command thus performs two operations: it fetches changes from a remote branch, then merges them into the current branch.


Here are some questions we will be discussing at the beginning of L03.

Git next steps

Congratulations, you now know enough git to finish this course.

There is lots more to learn, particularly about branching and collaboration. If you want to get a big(ger) picture view, a good place to start is Git Concepts Simplified.

Posted Mon 11 Sep 2023 08:30:00 AM Tags: /tags/git
Lab 1

Before the lab

Before every lab in this course, you will be given tasks to complete. These will generally be easy tasks like watching videos, but you need to complete them in order to keep with the class.

Command Line Familiarity Check

  1. In an FCS linux lab (remote or locally) log in, and open a terminal.

  2. Make a directory *

  3. Create a file in that directory using one of the available text editors

  4. Now clean up, removing the file and the directory.

If any of this was new to you, then please take the time to go through parts 1 to 5 of the Learning the Shell Tutorial.

Read the course syllabus.

The Course Syllabus is available on line. Please read it, and bring any questions you have about it to the first lab.