4 |
5 | int main() {
6 | double x;
7 | int i = 3;
8 | x = 1.0 / (double) i; /* cast i to double */
9 | double y = sin(x);
10 | printf("i = %d, x = %f, y = %f\n", i, x, y);
11 | return 0;
12 | }
13 |
--------------------------------------------------------------------------------
/lecture2/git_intro/Makefile:
--------------------------------------------------------------------------------
1 | all: reveal beamer pdf
2 |
3 | reveal:
4 | pandoc --self-contained --variable theme="simple" -t revealjs -s github.md -o github.html
5 |
6 | beamer:
7 | pandoc -t beamer -s github.md -o github_slides.pdf
8 |
9 | pdf:
10 | pandoc -t beamer -s github.md -o github.pdf
11 |
--------------------------------------------------------------------------------
/lecture2/git_intro/github.md:
--------------------------------------------------------------------------------
1 | ---
2 | title: 'Intro to GitHub'
3 | author: "Spencer Lyon"
4 | date : "2016-02-05"
5 | ---
6 |
7 | # Git `remote`s
8 |
9 | ## What's a `remote`?
10 |
11 | - A git repo can be on your hard drive: called local
12 | - A `remote` is a copy of the repository on someone else's hard drive or server
13 | - You `git push` commits from local to remote
14 | - `git pull` commits from remote to local
15 |
16 | ## Collaboration
17 |
18 | - Working with remotes enables many [workflows](https://git-scm.com/book/en/v2/Distributed-Git-Distributed-Workflows)
19 | - One common workflow (image taken from [here](https://git-scm.com/book/en/v2/Distributed-Git-Distributed-Workflows))
20 |
21 | 
22 |
23 | # [GitHub](https://github.com)
24 |
25 | ## Facts
26 |
27 | - GitHub is a common place to have a `remote`
28 | - [Over 2.2 million](http://githut.info) active repositories
29 | - Unlimited free public repositories
30 | - 5 free private repositories for academics
31 |
32 | ## GitHub Collaboration
33 |
34 | - Permission management: only certain users can `push`
35 | - Forking: anyone can create a copy of any (visible) repository under their account
36 | - Pull requests: system for project maintainers to review proposed changes before accepting them
37 | - Automated testing (CI) and coverage
38 |
39 | # Example
40 |
41 | ## quantecon_nyu_2016
42 |
43 | - Add this lecture to course repo
44 | - Steps:
45 | 1. Login to github (online)
46 | 2. Clone repository
47 | ```sh
48 | git clone https://github.com/jstac/quantecon_nyu_2016.git
49 | ```
50 | 3. Fork repository (online)
51 | 4. Add `remote` that points to fork
52 | ```sh
53 | git remote add fork https://github.com/spencerlyon2/quantecon_nyu_2016.git
54 | ```
55 |
56 | ## Steps (continued)
57 |
58 | - More steps
59 | 5. `add` + `commit` files
60 | ```
61 | git add files
62 | git commit -m "Adding github intro slides"
63 | ```
64 | 6. `push` to fork
65 | ```
66 | git push fork master
67 | ```
68 | 7. Open pull request (online)
69 |
70 | # Exercise
71 |
72 | ## Pushing homework
73 |
74 | - We will let you practice hw submission process
75 | - Steps
76 | - Create account on github
77 | - Clone [homework repository](https://github.com/jstac/quantecon_nyu_2016_homework)
78 | - Fork homework repo
79 | - Add your fork as remote
80 | - Create file `firstname_lastname` in folder `hw_github_intro`
81 | - Leave short message in file
82 | - Add and commit the file
83 | - Push to fork
84 | - Submit pull request
85 |
86 |
87 | # Extras
88 |
89 | ## SSH keys
90 |
91 | - Two modes of authenticating to github: https, SSH
92 | - https will require you to enter password on every push
93 | - Adding ssh-key removes this requirement
94 | - Follow these steps:
95 | - `ssh-keygen`: follow prompts
96 | - Copy the output of `cat ~/.ssh/id_rsa.pub` (use shift-c)
97 | - NOTE: path `~/.ssh/id_rsa.pub` might be different depending on your answers to previous step
98 | - Important part is to get the `.pub` version
99 | - Go to github account [settings](https://github.com/settings/profile)
100 | - Click "ssh keys" link on left, then "New ssh key"
101 | - Give it a title (name) and paste clipboard contents in key
102 | - Click big green "add SSH key button"
103 |
--------------------------------------------------------------------------------
/lecture2/git_intro/gitnotes.html:
--------------------------------------------------------------------------------
1 | Version Control with Git
2 |
3 |
4 |
I suspect that the most of us have participated in some sort of "home-rolled" version of version control. For example, below are three forms of "collaboration" that we might have engaged in
6 |
7 | - Tediously "careful" approach: This is when a person (or people) maintain a type of version control by placing the date edited at the end of the file name and then maintaining a full folder of these types of files.
8 | - Stake your claim approach: This appraoch takes the form of calling "dibs" on the use of a specific file for the time being by shouting across the office or sending emails to your collaborators and informing others that the file is "currently under your control" and that others should stay away!
9 | - Where's that email approach: Perhaps worst of all is the approach in which collaborators each maintain their own file and email it back and forth with changes as they make them.
10 |
11 | All of these are dangerous workflows and will result in mistakes and unwanted material showing up in your files (or wanted material being erased). Luckily for us, a variety of version control products have evolved in order to help us eliminate the need for these types of behaviors. Dropbox, Google Drives, SVN, Mercurial, and git are all examples of version control systems.
12 | Version control allows us to keep track of what changes have been made over time. Careful maintenance of code and data is vital to reproducibility which "is the hallmark of good science." While Dropbox and Google Drives may be useful for sharing certain types of files (I am not an advocate of their complete abandonment), they are not suitable for the fine tuned version control that we need to maintain good science (or software).
13 | What is git?
14 | Git is a distributed version control system. Distributed version control means that the entire history of every file is kept on your computer. It was originally written by Linus Torvalds (creator of Linux) to help maintain the Linux project (Fun Fact: Git was originally written because Torvalds found all other alternatives of version control to be too slow to manage a project as large as Linux, so he decided to write his own version which he began on 3 April 2005 and started being used on 7 April 2005. Read more about the history).
15 | Using git
16 | Many people associate git with the cloud based repository service Github, but git can be run independently either just on your own computer or on a self-hosted server. In this short tutorial, we are going to create a git repository hosted on our computer. We will then talk about some of the day to day commads that will be used in git.
17 | WARNING: Until you know what you're doing and exactly how they work, NEVER use the -f or --force flags no matter what the internet tells you.
18 | We are now going to walk through some of the basic settings you should set and an example of some commands.
19 | Configuration
20 | Here we deal with configuration details such as our default editor, user name, email, colors, etc...
21 |
22 | - Set name:
git config --global user.name FirstName LastName
23 | - Set email:
git config --global user.email email@email.com
24 | - Sets git colors:
git config --global color.ui "auto"
25 | - Sets editor to vim:
git config --global core.editor "vim"
26 |
27 | Creating a folder
28 | We will create a folder called <MyFirstGitRepo> using mkdir <MyFirstGitRepo>
29 | Initializing a git repository
30 | Now enter that directory using cd <MyFirstGitRepo>. To initialize this directory as a git repository (which in the background will create a series of directories and files) we will use the command git init.
31 | We can see the things that were created by typing ls .git, but don't worry too much about what is being kept inside yet.
32 | Four Stages of Files
33 | Files in a git repository can be in four different stages: untracked, unstaged, staged, and committed.
34 |
35 | - Untracked: This is a new file that your repository hasn't seen before.
36 | - Unstaged: A file that has previously been tracked and saved, but has changed since its last version.
37 | - Staged: A file that has been changed and is prepared to be committed. Nothing is set in stone yet though and new changes can be made.
38 | - Committed: When a file is committed it becomes a piece of the history of the repository. This moment of time in the file will be able to be referenced or referred to in the future.
39 |
40 | The picture below illustrates this "life cycle"
41 |
42 |
43 |
Let's illustrate this through an example and to expose ourselves to the commands that will be helpful: git add, git commit, git diff, and git status.
45 | First let's check what is new in our repository. Type git status. What does it say? It should say that there is nothing to commit because we haven't done anything yet.
46 | Now let's create a file called README.md. Open this file and type your name in it (could also use the command echo "FirstName LastName" >> README.md). If you type git status now, what do you see? It should list README.md as an untracked file.
47 | We can move this file from untracked to staged by using git add README.md. Type this command and then once again type git status. Our README.md file now shows up in green as a change to be committed. This means it is staged.
48 | We can take our "snapshot" of the file by using the command git commit -m "Type a meaningful msg here". Commit the file and then once again type git status. What do you see now? The repository should be clean again.
49 | Add something new to the README.md file. Once again, we can check the status of our git repository by typing git status. It will tell us that README.md is unstaged because we have made changes to it.
50 | Imagine we wanted to double check the things that we changed. We could type git diff README.md which will show us the changes that have been made to that file since its previous commit.
51 | These commands will be the core of your git workflow so I suggest familiarizing yourself with what they do.
52 | Commit History
53 | Remember how we can leave ourselves commit messages. It is useful to leave meaningful commit messages because they are left as a guide for yourself. We can see our history of commits by typing git log. We can do this in several formats: Try git log --pretty=oneline, git log --stat, git log --since=2.weeks, etc... See the Git Pro book for more options.
54 | If we want to return to a previous commit in our history we can use the information from git log to get back. There is a sequence of numbers and letters, which we will call commit hash, at the top of each entry in your history. If you copy this and type git reset <commit hash> then it will return us to that moment of our history. All of our more recent changes will be there, but they will be as if they had been just staged. Can use git reset <commit hash> --hard to reset to a previous point in time and delete all changes, but be very careful with that command as it can erase your history (in fact, I suggest not using it until you really know enough that you know it is what you want).
55 | Branching
56 | A branch is essentially an specific version of your folder. You start with a main branch which is called master. When you create another branch, it is an exact replica of the branch it is being created from (typically master) and includes the full history of the repository. After creating a new branch you can make changes and this new branch will develop its own history (without changing the history of the original branch -- such as master). If you decide you like the changes that you made then you can bring them into the original branch.
57 | The command git checkout is used for a few different things, but we will mostly use it for switching between branches. When used with the -b flag, it creates a new branch and switches to it.
58 | Let's create a new branch in our repository. git checkout -b test. What has changed? Let's look at the output of git branch. Now let's make some changes in our branch.
59 | > echo "New line" >> README.md
60 | > git add README.md
61 | > git commit -m "Branch update"
62 | > git log
63 | We can see the history has changed and we have a new commit. Let's return to the master branch by typing git checkout master. Now check git log, notice that we no longer have the changes from our test branch.
64 | Imagine that we decided to bring those changes into our master branch. We could use the git merge command by typing git merge test which will merge the branch test into the current branch.
65 | Ignore Files
66 | Sometimes there are files that get created via an intermediate process (such as .aux, .synctex, etc... in latex). We often don't care about keeping track of these files. Another wonderful thing about git is that it allows us to ignore files we don't care about!
67 | We do this by creating a file called .gitignore at the initial directory of our git repository.
68 | For example, echo *.garbage >> .gitignore.
69 | Then create a file called foo.garbage with touch foo.garbage.
70 | Now type git status. Notice that this file doesn't show up! It is because it recognizes that anything with an ending of .garbage should be ignored (this is because * is treated as a wildcard. Read more about regular expressions or wild cards for more information on how to use them).
71 | Resources and References
72 | Below is a sequence of references to things that I have found useful. I suggest reading a few of them and at least skimming the majority of them. In particular, the software carpentry lectures on git are very useful for learning the basics -- The Pro Git book is the biblical reference for git and can likely answer any question you will have for at least a few years to come. I have organized both sections by how relevant/convincing I found the documents.
73 | Git Technical References
74 | Software Carpentry: Git Lectures Pro Git Git Tower
75 | Why Git References
76 | Difference between git and Dropbox Version control for scientific research Why Physicists Should Use Git Or Why Everyone Should Try Git Git can facilitate greater reproducibility and increased transparency in science
77 |
--------------------------------------------------------------------------------
/lecture2/git_intro/gitnotes.md:
--------------------------------------------------------------------------------
1 | # Version Control with Git
2 |
3 |
4 |
5 |
60 |
61 |