Git

We will provide you with every exercise as its own git repository, which gives you a few useful tools. The initial commit, i.e. the clean templates is tagged as clean.

git status: check the files changed since last commit (the first commit, labelled clean, is the empty template)
git diff: get a detailed list of changes since last commit
git diff clean: perform a diff with the tag clean, i.e. the templates we provide.
git add -p: add a file in interactive mode (allows for finer control than plainly git add)
git add -u: add all modified files
git commit: create a commit with all changes included with git add
git checkout -p: interactively discard (!) changes since last commit. Essentially anything you can see in git diff.
git log: get a list of commits performed in this project.

To go back to the initial state of the template you could:

Commit or stash any current progress: git stash --include-untracked
Checkout the tag clean: git checkout clean
Read the output of git regarding creating a new branch.

How to revert file `test.cpp` to template without losing your work

git add test.cpp: add your test.cpp
git commit -m "This is where I stopped": commit your files (with a useful message)
git checkout clean -- test.cpp: check out test.cpp from tag clean, i.e. empty template
Do whatever you need to do with the template here
- If you havven't performed any git commit you can get the state of test.cpp you saved by git checkout master -- test.cpp
- otherwise you do git checkout <hash> -- test.cpp where hash is the hash of the git commit from which you want to restore the file (which you can find with git log).

Online repositories

If you want to create an online repository for your exercises, you can use any of the available platforms (eg github, gitlab, bitbucket...). Create an empty repository there, set it as remote for your project, and push your changes. We can help you with these steps if you are interested. Please first google how to set up a 'remote repository' as the 'origin' of your local repository.

SSH Keys

You might want these. Essentially it works like this: you have to keys. A private one, top-secret, and a public one, which is meant to be public. Using the public key the remote server can encrypt something that only the owner of the corresponding private key can decrypt. You have two things to do. First create a key pair. Look at the archlinux wiki; and then install the public key in the remote server, i.e. github, gitlab, etc. Instructions on how to do this you find in the documentation of the corresponding service.

Shortcuts

For Mac and Linux, you should have a file ~/.gitconfig. You can add (among other useful things) aliases there for convenience. You can do this by adding the following lines:

[alias]
  ai = add --interactive
  br = branch
  ci = commit
  co = checkout
  di = diff
  st = status

  gr = log --graph --full-history --all --color
  --pretty=tformat:"%x1b[31m%h%x09%x1b[32m%d%x1b[0m%x20%s%x20%x1b[33m(%an)%x1b[0m"

...or whatever your preferred shortcuts are. The last one is a nicer version of git log. If you work in Windows, good luck!

Building

For those that choose not to use an IDE (please reconsider!), from the root directory of the exercise (ie the one containing CMakeLists.txt), the command-line process for compiling should be:

Create a folder and switch to it: mkdir build && cd build
Generate the build system, e.g. Makefile with instruction to compile with flags suitable for debugging: cmake -DCMAKE_BUILD_TYPE=Debug ..
Type make VERBOSE=1
Repeatedly type make to rebuild you project.

Advanced build instructions

Some of our exercises will have support for clang-tidy. You can activate this as follows:

mkdir build-tidy && cd build-tidy
CC=clang CXX=clang++ cmake -DHAS_CLANG_TIDY=1 -DCMAKE_BUILD_TYPE=Debug ..

(You can also choose Release instead of Debug.)

You might need to change the line above depending on your system, e.g. clang-6.0 instead of lang. Setting MAKE_BUILD_TYPE to Release will produce faster code, but harder to debug.

You can have multiple folders, e.g. build-debug and build-release and easily switch between running binaries optimized for debugging or runtime.

Tests

Some exercises come with a battery of unit tests. These will typically be found at a folder unittests in your build directory.

Get into a habit of testing your own code. You can also write short examples of how to use libraries and test if your understanding of how the library should work is consistent with what the authors thinks it should do. In production code this is useful to automatically test any assumptions you make about how the library work. When the library changes its behaviour you will be notified first time you run your unit-tests compiled against the new library.

Run it as ./unittest/unittest to get an idea of whether your implementation so far has any bugs. Correct unit tests are not a guarantee of correct code!

Git