Before the lab
- Make sure you can push to coursegit from an FCS linux machine. A good
way to test this is to push a (work in progress) journal entry for Lab 1.
- Test that your push was successful by cloning the repo, per the instructions in faq. After cloning,
change directory to
journal/
and run raco frog -bp
- Read about how to write a good commit message in §5.2 of Pro Git
- Read Section 2 of FICS
Background
Git Tutorial Continued
Making Changes in git
- Time
- 20 minutes
- Activity
- Individual work
- Summary
- 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
- Time
- 15 minutes
- Activity
- Individual work
- Summary
- 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.
- to see the effect of a
git add
command, run git diff --cached --stat
- to undo the effect of a
git add
command, run git reset
.
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
- Time
- 15 minutes
- Activity
- Small group discussion, presenting work to the group, peer feedback
- Summary
- Reinforce idea of commit message quality
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
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.
Find something positive to say about the other commit messages you
are reading.
Find a constructive improvement with one of the other
messages. Don't be mean, people have varying levels of experience
with this.
Getting started with racket
Hello Racket World
- Time
- 15 Minutes
- Activity
- Group walkthrough
#lang htdp/bsl
"hello world"
(* 6 7)
Command Line
DrRacket: A Racket Specific IDE
Start DrRacket from the activities menu
Referring to the
DrRacket documentation
as needed, open and run the hello.rkt
program from the previous
part.
What is the meaning of the first line of the file?
Racket Expressions.
- Time
- 20 minutes
- Activity
- Small groups
Form groups of 2 or 3.
Work through Exercise 0: for each of the following lines of code, someone from the group should guess what is wrong before trying it in the Interactions window of DrRacket.
(* (5) 3)
(+ (* 2 4)
(5 * 14)
(* + 3 5 2)
(/ 25 0)
Work through Exercise
1. In
general where the text asks you to predict the value of an expression,
you can also enter into the definitions window something like
(check-expect (* 6 9) 42)
When you run (e.g. F5), then you will find out if your prediction
is correct.
Work through Exercise
2. You can test your answers by applying the following functions to appropriate arguments. Notice that the value of y
does not matter.
#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
- Time
- 20 minutes
- Activity
- 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)
- Do these tests suffice? Why or why not?
Before Next Lab
Reading
Git Practice: Working with multiple git repos
- Time
- 15-30 minutes
- Activity
- Individual work, outside scheduled lab time.
Cloning
Open a terminal.
Make a directory lab2-scratch
somewhere
outside the cs2613
git repository you created earlier.
Now move to the lab2-scratch
directory, and make a clone of the
central repo.
$ git clone -b main 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
Open a terminal
Navigate to the ~/lab2-scratch/cs2613-clone/journal
directory.
create a new blog entry, and commit it.
Push your changes back to the central repository.
$ git push origin main
Change directory to your original directory
~/cs2613
. Bring in the changes you made
$ git pull origin main
This merges the changes from the central copy of "main" 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.
Questions
Here are some questions we will be discussing at the beginning of L03.
- What is a remote?
- What is merging?
- What is a conflict?
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.