From a90e2b4048c6ddb0e486174e648aba05b75b3eb0 Mon Sep 17 00:00:00 2001 From: Gerko Vink Date: Wed, 16 Oct 2024 10:45:15 +0200 Subject: [PATCH] my 3 words --- docs/search.json | 18 ++++++++++++++---- docs/story.html | 3 ++- story.qmd | 3 ++- 3 files changed, 18 insertions(+), 6 deletions(-) diff --git a/docs/search.json b/docs/search.json index 3a4ec9c..4c9c92e 100644 --- a/docs/search.json +++ b/docs/search.json @@ -284,7 +284,17 @@ "href": "week 3.html#git-and-github", "title": "3  Version Control", "section": "3.4 Git and GitHub", - "text": "3.4 Git and GitHub\n\n3.4.1 Git\nGit is a free and open source version control system for text files. It can handle extensive change logging for you, no matter the size of the project. Git is fast and efficient, but its effectiveness depends also on the frequency you instruct it to log your project’s changes.\nYou can see Git as a blank canvas that starts at a certain point in time. Every time you (or others) instruct Git to log any changes that have been made, Git adds the changes that are made to this canvas. We call the changes to the canvas commits. With every commit an extensive log is created that includes at least the following information:\n\nthe changes made\nwho made the changes\nmetadata\na small piece of text that describe the changes made\n\nThe difference between two commits - or the changes between them - are called diffs.\nIf you’d like to know much more about Git, this online book is a very good resource. If you’d like to practice with the command line interface use this webpage for a quick course. This book covers pretty much everything you need to marry Git and R.\n\n\n\n3.4.2 GitHub\nGitHub is the social and user interface to Git that allows you to work in repositories. These repositories can be seen as project folders in which you publish your work, but you can also use them as test sites for development, testing, etcetera. There is a distinction between private repositories (only for you and those you grant access) and public repositories (visible for everyone).\nYour public repositories can be viewed and forked by everyone. Forking is when other people create a copy of your repository on their own account. This allows them to work on a repository without affecting the master. You can also do this yourself, but then the process is called branching instead of forking. If you create a copy of a repository that is offline, the process is called cloning.\nGitHub’s ability to branch, fork and clone is very useful as it allows other people and yourself to experiment on (the code in) a repository before any definitive changes are merged with the master. If you’re working in a forked repository, you can submit a pull request to the repository collaborators to accept (or reject) any suggested changes.\nFor now, this may be confusing, but I hope you recognize the benefits GitHub can have on the process of development and bug-fixing. For example, the most up-to-date version of the mice package in R can be directly installed from the mice repository with the following code:\n\ninstall.packages(\"devtools\")\ndevtools::install_github(repo = \"stefvanbuuren/mice\")\n\nYou can see that this process requires package devtools that expands the R functionality with essential development tools. Loading packages in R directly from their respective GitHub repositories, allows you to obtain the latest - often improved and less buggy - iteration of that software even before it is published on CRAN.\n\n\n\n3.4.3 Installing Git\n\n3.4.3.1 Installing on Mac\nI suggest you install Git by downloading and installing GitHub Desktop. GitHub’s desktop application is a nice GUI and, naturally, integrates well into the repository workflow on GitHub.\nWhen installed, you can go to GitHub Desktop > Install Command Line Tool\nAfter a reboot, all should be set.\n\n\n3.4.3.2 Installing on Windows\nDownload and install Git for Windows, Then download and install GitHub Desktop. GitHub’s desktop application is a nice GUI and, naturally, integrates well into the repository workflow on GitHub.\nAfter a reboot, all should be set.\n\n\n\n\n3.4.4 Command line interface vs. GUI\nUltimately, you’ll want to learn how to use Git through the command line interface (CLI). It offers better and more comprehensive functionality. Again, take this 15-minute course to get a gentle introduction. But do not be afraid that you miss out on the CLI if you don’t study this link: In week 4 we’ll explore in detail how to handle Git when things go haywire. You’ll be a CLI-wizard by then.\n\n\n\n3.4.5 .gitignore\nGitHub sees every file in your repository as one of the following three\n\ntracked files that have been (previously) staged and committed\nuntracked files that have not been staged or committed\nignored files that have been explicitly ignored\n\nIt may be wise to instruct Git to ignore changes in some files. For example, compiled files (think about .com, .exe, .o, .so, etc), archives (e.g. .zip, .tar, .rar), logs (.log) and files generated in runtime (.temp) do not have to be tracked by Git. The same holds for hidden system files (e.g. .DS_Store or Thumbs.db). Adding such filetypes to a file named .gitignore and placing that file in the root of your repository will take care of focusing Git’s energy on useful files only. For common .gitignore examples, see this repository. There are many examples inside, such as this .gitignore example for R\n\n\n\n3.4.6 Linking GitHub and RStudio\nSecurely linking your local machine to the remote repository is vital when collaborating with other people. In short; you would not want a potential hacker to have contributor access to any of your projects. I have prepared this walkthrough video that details the process of linking GitHub to your machine and RStudio. Below I explain the rationale of using both an SSH key and a personal access token.\nIf you still experience problems after following my walkthrough, check this chapter\nTo learn more about maintaining a package as GitHub repository within RStudio, have a look at this guide by Hadley Wickham.\n\n\n\n3.4.7 SSH keys\nWith an SSH key you can identify yourself to an online server (in this case the GitHub server) without having to log in every time. It is like your machine having access to an online server through a unique biometric security measure, but instead of biometric data a bits-and-bytes hash code is communicated every time. You can use an SSH key to link RStudio to your GitHub repository, but it is better to use a personal access token for this. See below.\n\n\n\n3.4.8 Personal access tokens\nIf you use GitHub’s 2FA functionality - you should! - your username and password are not sufficient to push commits to GitHub through RStudio. To solve this follow these steps on github.com like I detail in this walkthrough video:\n\nLog in to your account\nClick on your profile photo (upper right corner) and select Settings\nGo to Developer settings\nSelect Personal access tokens in the left sidebar. The classic token as it is now called is sufficient\nClick Generate new token\nGive the token a name\nSelect at least the repo scope; you’ll need these permissions to access repositories. Also choose a relevant expiration: the longer the better, the shorter the safer. Remember that you can always generate a new token if you need to.\nClick Generate token\n\nCopy the token. The token will not be displayed again, so copy-paste it directly where it is needed. Remember that you can always generate a new token if you need to.\nIn RStudio, paste the generated token in the password field when RStudio asks for your credentials. The token will now serve as the unique authenticated link instead of your password.\n\n\n\n3.4.9 Git exercise\n\nFork this year’s course repository. You can do this by clicking the Fork button on the top right of the repository page. This will create a copy of the repository on your own GitHub account.\nClone the fork to your machine. You can do this by clicking the green Code button and copying the URL. Then open RStudio and go to File > New Project > Version Control > Git. Paste the URL in the Repository URL field and choose a directory where you want to store the repository on your machine.\nCreate a new branch called wk3\nUpdate the file story.qmd by adding three words to the sentence and commit the changes. You can do this by clicking on the Git tab in RStudio, selecting the files you want to commit (only one in this case!), writing a commit message and clicking the Commit button.\nPush to your GitHub fork. You can do this by clicking the green Push button in the Git tab in RStudio or by using\nSend a pull request (PR) to incorporate your changes into the upstream/main branch (i.e. gerkovink/markup@main). You can do this by going to your fork on GitHub and clicking the Pull request button. Make sure to select the correct branches.\nIf you’re fast enough, your commit will not result in a conflict. We will merge the PR’s in the order they are presented in, as long as there are no conflicts.\nIf need be, update your PR by simply submitting another commit and pushing it to your fork. This will update the PR automatically.\n\n\n\n\n\n\n\n\nMonte Carlo simulation exercise (no need to hand in)\n\n\n\n\nPerform a small simulation that does the following:\n\n\n\nSample 100 samples from a standard normal distribution.\nFor each of these samples, calculate the following statistics for the mean:\n\n\nabsolute bias\nstandard error\nlower bound of the 95% confidence interval\nupper bound of the 95% confidence interval\n\n\nCreate a plot that demonstrates the following:\n\n“A replication of the procedure that generates a 95% confidence interval that is centered around the sample mean would cover the population value at least 95 out of 100 times” (Neyman, 1934)\n\nPresent a table containing all simulated samples for which the resulting confidence interval does not contain the population value.\n\n\n\n\n\n\n\n\n\nMy solutions to the exercises\n\n\n\n\n\n\nMy old solution to the MC exercise\nMy solution to the MC exercise as I would do it now", + "text": "3.4 Git and GitHub\n\n3.4.1 Git\nGit is a free and open source version control system for text files. It can handle extensive change logging for you, no matter the size of the project. Git is fast and efficient, but its effectiveness depends also on the frequency you instruct it to log your project’s changes.\nYou can see Git as a blank canvas that starts at a certain point in time. Every time you (or others) instruct Git to log any changes that have been made, Git adds the changes that are made to this canvas. We call the changes to the canvas commits. With every commit an extensive log is created that includes at least the following information:\n\nthe changes made\nwho made the changes\nmetadata\na small piece of text that describe the changes made\n\nThe difference between two commits - or the changes between them - are called diffs.\nIf you’d like to know much more about Git, this online book is a very good resource. If you’d like to practice with the command line interface use this webpage for a quick course. This book covers pretty much everything you need to marry Git and R.\n\n\n\n3.4.2 GitHub\nGitHub is the social and user interface to Git that allows you to work in repositories. These repositories can be seen as project folders in which you publish your work, but you can also use them as test sites for development, testing, etcetera. There is a distinction between private repositories (only for you and those you grant access) and public repositories (visible for everyone).\nYour public repositories can be viewed and forked by everyone. Forking is when other people create a copy of your repository on their own account. This allows them to work on a repository without affecting the master. You can also do this yourself, but then the process is called branching instead of forking. If you create a copy of a repository that is offline, the process is called cloning.\nGitHub’s ability to branch, fork and clone is very useful as it allows other people and yourself to experiment on (the code in) a repository before any definitive changes are merged with the master. If you’re working in a forked repository, you can submit a pull request to the repository collaborators to accept (or reject) any suggested changes.\nFor now, this may be confusing, but I hope you recognize the benefits GitHub can have on the process of development and bug-fixing. For example, the most up-to-date version of the mice package in R can be directly installed from the mice repository with the following code:\n\ninstall.packages(\"devtools\")\ndevtools::install_github(repo = \"stefvanbuuren/mice\")\n\nYou can see that this process requires package devtools that expands the R functionality with essential development tools. Loading packages in R directly from their respective GitHub repositories, allows you to obtain the latest - often improved and less buggy - iteration of that software even before it is published on CRAN.\n\n\n\n3.4.3 Installing Git\n\n3.4.3.1 Installing on Mac\nI suggest you install Git by downloading and installing GitHub Desktop. GitHub’s desktop application is a nice GUI and, naturally, integrates well into the repository workflow on GitHub.\nWhen installed, you can go to GitHub Desktop > Install Command Line Tool\nAfter a reboot, all should be set.\n\n\n3.4.3.2 Installing on Windows\nDownload and install Git for Windows, Then download and install GitHub Desktop. GitHub’s desktop application is a nice GUI and, naturally, integrates well into the repository workflow on GitHub.\nAfter a reboot, all should be set.\n\n\n\n\n3.4.4 Command line interface vs. GUI\nUltimately, you’ll want to learn how to use Git through the command line interface (CLI). It offers better and more comprehensive functionality. Again, take this 15-minute course to get a gentle introduction. But do not be afraid that you miss out on the CLI if you don’t study this link: In week 4 we’ll explore in detail how to handle Git when things go haywire. You’ll be a CLI-wizard by then.\n\n\n\n3.4.5 .gitignore\nGitHub sees every file in your repository as one of the following three\n\ntracked files that have been (previously) staged and committed\nuntracked files that have not been staged or committed\nignored files that have been explicitly ignored\n\nIt may be wise to instruct Git to ignore changes in some files. For example, compiled files (think about .com, .exe, .o, .so, etc), archives (e.g. .zip, .tar, .rar), logs (.log) and files generated in runtime (.temp) do not have to be tracked by Git. The same holds for hidden system files (e.g. .DS_Store or Thumbs.db). Adding such filetypes to a file named .gitignore and placing that file in the root of your repository will take care of focusing Git’s energy on useful files only. For common .gitignore examples, see this repository. There are many examples inside, such as this .gitignore example for R\n\n\n\n3.4.6 Linking GitHub and RStudio\nSecurely linking your local machine to the remote repository is vital when collaborating with other people. In short; you would not want a potential hacker to have contributor access to any of your projects. I have prepared this walkthrough video that details the process of linking GitHub to your machine and RStudio. Below I explain the rationale of using both an SSH key and a personal access token.\nIf you still experience problems after following my walkthrough, check this chapter\nTo learn more about maintaining a package as GitHub repository within RStudio, have a look at this guide by Hadley Wickham.\n\n\n\n3.4.7 SSH keys\nWith an SSH key you can identify yourself to an online server (in this case the GitHub server) without having to log in every time. It is like your machine having access to an online server through a unique biometric security measure, but instead of biometric data a bits-and-bytes hash code is communicated every time. You can use an SSH key to link RStudio to your GitHub repository, but it is better to use a personal access token for this. See below.\n\n\n\n3.4.8 Personal access tokens\nIf you use GitHub’s 2FA functionality - you should! - your username and password are not sufficient to push commits to GitHub through RStudio. To solve this follow these steps on github.com like I detail in this walkthrough video:\n\nLog in to your account\nClick on your profile photo (upper right corner) and select Settings\nGo to Developer settings\nSelect Personal access tokens in the left sidebar. The classic token as it is now called is sufficient\nClick Generate new token\nGive the token a name\nSelect at least the repo scope; you’ll need these permissions to access repositories. Also choose a relevant expiration: the longer the better, the shorter the safer. Remember that you can always generate a new token if you need to.\nClick Generate token\n\nCopy the token. The token will not be displayed again, so copy-paste it directly where it is needed. Remember that you can always generate a new token if you need to.\nIn RStudio, paste the generated token in the password field when RStudio asks for your credentials. The token will now serve as the unique authenticated link instead of your password.", + "crumbs": [ + "3  Version Control" + ] + }, + { + "objectID": "week 3.html#exercise-1-git-started-with-github", + "href": "week 3.html#exercise-1-git-started-with-github", + "title": "3  Version Control", + "section": "3.5 Exercise 1: Git started with GitHub", + "text": "3.5 Exercise 1: Git started with GitHub\n\nFork this year’s course repository. You can do this by clicking the Fork button on the top right of the repository page. This will create a copy of the repository on your own GitHub account.\nClone the fork to your machine. You can do this by clicking the green Code button and copying the URL. Then open RStudio and go to File > New Project > Version Control > Git. Paste the URL in the Repository URL field and choose a directory where you want to store the repository on your machine.\nCreate a new branch called wk3\nUpdate the file story.qmd by adding three words to the sentence and commit the changes. You can do this by clicking on the Git tab in RStudio, selecting the files you want to commit (only one in this case!), writing a commit message and clicking the Commit button.\nPush to your GitHub fork. You can do this by clicking the green Push button in the Git tab in RStudio or by using\nSend a pull request (PR) to incorporate your changes into the upstream/main branch (i.e. gerkovink/markup@main). You can do this by going to your fork on GitHub and clicking the Pull request button. Make sure to select the correct branches.\nIf you’re fast enough, your commit will not result in a conflict. We will merge the PR’s in the order they are presented in, as long as there are no conflicts.\nIf need be, update your PR by simply submitting another commit and pushing it to your fork. This will update the PR automatically.\n\n\n\n\n\n\n\n\nMonte Carlo simulation exercise (no need to hand in)\n\n\n\n\nPerform a small simulation that does the following:\n\n\n\nSample 100 samples from a standard normal distribution.\nFor each of these samples, calculate the following statistics for the mean:\n\n\nabsolute bias\nstandard error\nlower bound of the 95% confidence interval\nupper bound of the 95% confidence interval\n\n\nCreate a plot that demonstrates the following:\n\n“A replication of the procedure that generates a 95% confidence interval that is centered around the sample mean would cover the population value at least 95 out of 100 times” (Neyman, 1934)\n\nPresent a table containing all simulated samples for which the resulting confidence interval does not contain the population value.\n\n\n\n\n\n\n\n\n\nMy solutions to the exercises\n\n\n\n\n\n\nMy old solution to the MC exercise\nMy solution to the MC exercise as I would do it now", "crumbs": [ "3  Version Control" ] @@ -293,8 +303,8 @@ "objectID": "week 3.html#exercise-2-git-it-done", "href": "week 3.html#exercise-2-git-it-done", "title": "3  Version Control", - "section": "3.5 Exercise 2: Git it done", - "text": "3.5 Exercise 2: Git it done\nThis week we will also learn how to use \\(git\\) properly when we mess up. But let’s not learn that on this year’s repo ;-). Fork the an old course repository here, deselect! Copy the master branch only in order to copy all branches and checkout the Exercise_wk4 branch.\nLet’s continue this week with this second exercise.\n\n\n3.5.1 Disclaimer\nI’ll take you by the hand through the exercise. So if you follow this manual step by step, you’ll be done at the end and you will have a good notion of troubleshooting with Git [or a reference thereof].\nThis exercise is a summary of important commands. A full and comprehensive overview can be found in the pro Git book.\nO, and we forgot to tell you: you’ll need the terminal for this exercise. You may use the one in RStudio, or the dedicated terminal on UNIX systems or the command prompt or Windows Terminal on Windows.\n\n\n\n3.5.2 Prepare\nBefore we continue it is good to all start from the point of departure.\n\nUse the terminal to navigate to the Git repository (the location of the git repo on your HDD)\nType git pull to make sure that you obtain the latest state from the remote on GitHub\n\n\n% git pull\nAlready up to date.\n\nDon’t type the %; that is just the command prompt indicator on my machine. Yours may be different, such as > or $. We see that Git reminds me that I already have the latest state. I am up to date.\n\nChange the branch to the Exercise_wk4 branch.\n\n\n% git checkout Exercise_wk4\nSwitched to branch 'Exercise_wk4'\nYour branch is up to date with 'origin/Exercise_wk4'.\n\nI’ve now been switched to the Exercise_wk4 branch. It is up to date with origin/Exercise_wk4, meaning that GitHub and my local copy are in sync. origin is a shorthand name for the remote repository that a project was originally cloned from. It is useful that origin is referenced instead of the original repo’s URL –> This makes referencing much more convenient.\n\n\n\n3.5.3 Inspect the current state\nMake sure you are in the Exercise_wk4 branch. Then Use git log --graph to inspect the current Git branch and its commits.\n\n% git log --graph \n* commit 176137b1667cc6903f7a9eead5723892ef1a77a7 (HEAD -> master, origin/master, origin/HEAD)\n|\\ Merge: 0e67723 c902093\n| | Author: Gerko Vink <g.vink@uu.nl>\n| | Date: Thu Oct 29 12:44:01 2020 +0100\n| | \n| | Merge pull request #38 from thomasjwise/wisedev\n| | \n| | Assignment 3 - Beamer PDF\n| | \n| | Well done ✅\n| | \n| * commit c9020931678d90d91cfe21778e6ce5b4943e46cb\n| | Author: Thomas Wise <48682160+thomasjwise@users.noreply.github.com>\n| | Date: Wed Oct 28 13:59:23 2020 +0100\n| | \n| | Assignment 3 - Beamer PDF\n| | \n* | commit 0e67723572744b769389f5b8883c9f1aa6a3b7dd\n|\\ \\ Merge: 4134b75 1f488c6\n| | | Author: Gerko Vink <g.vink@uu.nl>\n| | | Date: Thu Oct 29 11:27:16 2020 +0100\n| | | \n\nWe see information about the history that brought us to this point in time. We see commit messages, the author, the dates, the SHA-1 hash and the graph tree. We asked for the graph tree with --graph.\nYou can scroll up and down the graph. To exit the graph window, type q. For help, type h. To obtain a more condensed graph, use\n\n% git log --oneline --graph\n* 176137b (HEAD -> Exercise_wk4, origin/master, origin/HEAD, origin/Exercise_wk4, master) Merge pull request #38 from thomasjwise/wisedev\n|\\ \n| * c902093 Assignment 3 - Beamer PDF\n* | 0e67723 Merge pull request #39 from gerkovink/SofieIssue\n|\\ \\ \n| * | 1f488c6 (SofieIssue) remove pipe operator\n| * | 4ead406 update readme.md\n|/ / \n* | 4134b75 Merge pull request #37 from pietjonker/piet\n|\\ \\ \n| * | f50014b commit assignment 2\n| * | 5ae2b9b Assignment 1 and 2\n* | | f277a35 Merge pull request #35 from zoedunias/zoedev\n|\\ \\ \\ \n| * | | 1c9aad6 Added Exercise 2\n* | | | 43fb1ed Merge pull request #34 from RianneKraakman/riannedev\n|\\ \\ \\ \\ \n| * | | | 75d9293 Add assignment 2\n* | | | | d3df110 Merge pull request #33 from gerkovink/gerkodev\n|\\ \\ \\ \\ \\ \n| * \\ \\ \\ \\ 34954f8 (origin/gerkodev, gerkodev) Merge pull request #22 from Goorbergh/ruben_assignment_1\n\nThis graph view is much more condensed. The nice thing about this view is the direct depiction of each action’s abbreviated SHA-1 key.\nWe can use the SHA-1 keys to instruct Git. For example, to obtain the history on commit c902093, we only need to refer the SHA-1 hash.\n\n% git log c902093 \ncommit c9020931678d90d91cfe21778e6ce5b4943e46cb\nAuthor: Thomas Wise <48682160+thomasjwise@users.noreply.github.com>\nDate: Wed Oct 28 13:59:23 2020 +0100\n\n Assignment 3 - Beamer PDF\n\ncommit db649539738bb30b63d93053b67891ef6c55037e\nAuthor: Thomas Wise <48682160+thomasjwise@users.noreply.github.com>\nDate: Wed Sep 16 14:04:21 2020 +0200\n\n Assignment 1\n\ncommit 21a3b5ac1535703f4ce0d6feb2ccf3703f95eee3\nMerge: 7f0806b f4a11cb\nAuthor: Gerko Vink <g.vink@uu.nl>\nDate: Tue Sep 15 20:15:25 2020 +0200\n\n Merge pull request #2 from gerkovink/gerkodev\n \n This image is too large\n\ncommit f4a11cbed729bc8454c01866aab4291b3b580d6f\nAuthor: Gerko Vink <g.vink@uu.nl>\n\nOr, a more condensed version of the same\n\n% git log c902093 --pretty=oneline\nc9020931678d90d91cfe21778e6ce5b4943e46cb Assignment 3 - Beamer PDF\ndb649539738bb30b63d93053b67891ef6c55037e Assignment 1\n21a3b5ac1535703f4ce0d6feb2ccf3703f95eee3 Merge pull request #2 from gerkovink/gerkodev\nf4a11cbed729bc8454c01866aab4291b3b580d6f resize image\n7f0806b68387d4f3c8af5c1f27d94b69e90a2d13 Merge pull request #1 from gerkovink/gerkodev\na36ed81b3831e6084c2adf661dc4cfb32c4cb5f7 add childhood memory\n9ba9c43437a7f00f5095df55db0c07d7233ad152 Add CV\n9bf1c32ea55b60bce613d65765c18deb522772ff Update .gitignore\n18761716665262f19296fb5d8e7c1720c8cea58a Merge branch 'master' of https://github.com/gerkovink/markup2020\n1ee60aa26142b5f175928d409614b8de84c1ef79 Update .gitignore\n7c3d816264b5629e7bfe112954178648d94a37b4 Delete markup_sticker_SMALL.psd\n37c356ca51b4ed03e96570934f28caf5fcfd75d8 Delete .DS_Store\nd56dd90172d1106117d53102e5053165bc182020 Update .gitignore\ne7b78b592a8000d3a647de3a265c69496adebfe5 Update .gitignore\nfdd923ad2b522d6e4357229ea801d23ec5b16717 update readme\n7e14559d7f7e8676d557c9b73fc43fb3a66a0c3c added sticker\n493609efa7ce659ebebf5a0d0300f23788397e68 Initial commit\n\nPlease note that we only reference the short hash. There is no need to reference the longer hash as long as the sequence of the shorter reference is unique.\nFrom this --pretty=oneline view it is now easy to spot the origin of our course repository - the initial commit that initiated the Git goodness. You can also see that I updated the .gitignore, a hidden file that specifies which files and directories to be ignored by Git. And I did some cosmetic changes and file deletions. This is very insightfull because of the detailed, but consice commit messages.\n\n\n\n3.5.4 Checkout an old state\nGo back in time to 21a3b5ac1535703f4ce0d6feb2ccf3703f95eee3 Merge pull request #2 from gerkovink/gerkodev.\nTo do so, we only need to refer the start of the SHA-1 key.\n\n% git checkout 21a3b5a\nNote: switching to '21a3b5a'.\n\nYou are in 'detached HEAD' state. You can look around, make experimental\nchanges and commit them, and you can discard any commits you make in this\nstate without impacting any branches by switching back to a branch.\n\nIf you want to create a new branch to retain commits you create, you may\ndo so (now or later) by using -c with the switch command. Example:\n\n git switch -c <new-branch-name>\n\nOr undo this operation with:\n\n git switch -\n\nTurn off this advice by setting config variable advice.detachedHead to false\n\nHEAD is now at 21a3b5a Merge pull request #2 from gerkovink/gerkodev\n\nWe are now at the old state. So we went back in time. The current state where we are is independent from all later commits, but is built exactly on all preceding commits as per the tree.\nThere are a couple of terms that are new:\n\nHEAD: The HEAD in Git is the pointer to the current branch reference. It is the last commit you have made or checked out [in our case]. REMEMBER that the head will always serve as the parent to the next commit\ndetached HEAD: The same as the head, but now the pointer references a specific commit and not a branch.\n\n\n\n3.5.4.1 The problem with a detached HEAD\nThis webpage illustrates the dangers of committing changes under a detached head quite nicely:\n\nThe HEAD pointer in Git determines your current working revision (and thereby the files that are placed in your project’s working directory). Normally, when checking out a proper branch name, Git automatically moves the HEAD pointer along when you create a new commit. You are automatically on the newest commit of the chosen branch. When you instead choose to check out a commit hash, Git won’t do this for you. The consequence is that when you make changes and commit them, these changes do NOT belong to any branch. This means they can easily get lost once you check out a different revision or branch: not being recorded in the context of a branch, you lack the possibility to access that state easily (unless you have a brilliant memory and can remember the commit hash of that new commit…).\n\nThe useful thing about going to an old commit is that you can take this state as a point of departure. Just beware of the pitfalls of working under a detached HEAD.\n\n\n\n3.5.4.2 leave the detached HEAD\nGo back to the branch HEAD\n\n% git switch - \nPrevious HEAD position was 21a3b5a Merge pull request #2 from gerkovink/gerkodev\nSwitched to branch 'Exercise_wk4'\nYour branch is up to date with 'origin/Exercise_wk4'.\n\n\n\n\n\n3.5.5 Make a new branch of the old state\nLet’s take that old state and make it into a proper point of departure for new things. Again, reference 21a3b5ac1535703f4ce0d6feb2ccf3703f95eee3 Merge pull request #2 from gerkovink/gerkodev, but now we make the state of 21a3b5a into a new branch. We call that branch Wk4_markup:\n\n% git checkout -b Wk4_markup 21a3b5a \nSwitched to a new branch 'Wk4_markup'\n\nWe now have checked out an old state and made it into a new branch. The cool thing is that we can now commit all we want and everything will be properly logged. Just remember that if you’d like to go back in time and play around with an old state of your project –> Merge the old state into a new branch like I demonstrated above.\n\n\n\n3.5.6 Add a new commit\nWe start by creating an empty text file\n\n% touch add_text_file.txt\n\nIf the touch command does not work on your machine, you may also create this file by hand. In a Windows-terminal, you can also use the comment:\n\nPS C:\\GitHub\\Markup2020> New-Item .\\add_text_file.txt -type file\n\nNow, if we would like to commit the addition of this file to our repo, we get the following:\n\n% git commit -a -m 'add text file'\nOn branch Wk4_markup\nUntracked files:\n add_text_file.txt\n\nnothing added to commit but untracked files present\n\nThe commit was not succesfull, because the file add_text_file.txt is not yet tracked. Note that I use -a to specify to commit all changed files and folders that are tracked. I use -m to indicate that I would like to add the message add text file.\nYou see that using a GUI to Git like GitHub desktop or RStudio is quite convenient if you would not like to indicate which files to track. It is also less flexible.\n\n\n3.5.6.1 Add files to tracking\nTo track all untracked files and folders\n\ngit add -A\n\n\n\n\n3.5.6.2 commit with a message\nNow if we revisit the commit command\n\n% git commit -a -m 'add text file'\n[Wk4_markup 8d30c46] add text file\n 1 file changed, 0 insertions(+), 0 deletions(-)\n create mode 100644 add_text_file.txt\n\n\n\n\n\n3.5.7 Study the log again\n\n% git log --pretty=oneline\n8d30c4698b9761d650de2f5288389257762753ce (HEAD -> Wk4_markup) add text file\n21a3b5ac1535703f4ce0d6feb2ccf3703f95eee3 (old-state) Merge pull request #2 from gerkovink/gerkodev\nf4a11cbed729bc8454c01866aab4291b3b580d6f resize image\n7f0806b68387d4f3c8af5c1f27d94b69e90a2d13 Merge pull request #1 from gerkovink/gerkodev\na36ed81b3831e6084c2adf661dc4cfb32c4cb5f7 add childhood memory\n9ba9c43437a7f00f5095df55db0c07d7233ad152 Add CV\n9bf1c32ea55b60bce613d65765c18deb522772ff Update .gitignore\n18761716665262f19296fb5d8e7c1720c8cea58a Merge branch 'master' of https://github.com/gerkovink/markup2020\n1ee60aa26142b5f175928d409614b8de84c1ef79 Update .gitignore\n7c3d816264b5629e7bfe112954178648d94a37b4 Delete markup_sticker_SMALL.psd\n37c356ca51b4ed03e96570934f28caf5fcfd75d8 Delete .DS_Store\nd56dd90172d1106117d53102e5053165bc182020 Update .gitignore\ne7b78b592a8000d3a647de3a265c69496adebfe5 Update .gitignore\nfdd923ad2b522d6e4357229ea801d23ec5b16717 update readme\n7e14559d7f7e8676d557c9b73fc43fb3a66a0c3c added sticker\n493609efa7ce659ebebf5a0d0300f23788397e68 Initial commit\n\nWe can see that the HEAD is now at the latest commit and that this commit comes after the old-state from which we created the branch.\n\n\n3.5.7.1 Now add another empty text file.\n\n% touch add_another_text_file.txt\n\nLet’s say that we rather would have included this file in the previous commit, we can achieve this by\n\n% git add -A\n% git commit --amend -m \"add two text files\"\n[Wk4_markup 9e6c38c] add two text files\n Date: Tue Nov 3 23:09:11 2020 +0100\n 1 file changed, 0 insertions(+), 0 deletions(-)\n create mode 100644 add_text_file.txt\n\nWe have effectively ammended the previous commit. We’ve also changed the commit message into add two text files:\n\n% git log --pretty=oneline\n9e6c38c2288f7e7fce75de3bd1ffb522de112a8b (HEAD -> Wk4_markup) add two text files\n21a3b5ac1535703f4ce0d6feb2ccf3703f95eee3 (old-state) Merge pull request #2 from gerkovink/gerkodev\nf4a11cbed729bc8454c01866aab4291b3b580d6f resize image\n7f0806b68387d4f3c8af5c1f27d94b69e90a2d13 Merge pull request #1 from gerkovink/gerkodev\na36ed81b3831e6084c2adf661dc4cfb32c4cb5f7 add childhood memory\n9ba9c43437a7f00f5095df55db0c07d7233ad152 Add CV\n9bf1c32ea55b60bce613d65765c18deb522772ff Update .gitignore\n18761716665262f19296fb5d8e7c1720c8cea58a Merge branch 'master' of https://github.com/gerkovink/markup2020\n1ee60aa26142b5f175928d409614b8de84c1ef79 Update .gitignore\n7c3d816264b5629e7bfe112954178648d94a37b4 Delete markup_sticker_SMALL.psd\n37c356ca51b4ed03e96570934f28caf5fcfd75d8 Delete .DS_Store\nd56dd90172d1106117d53102e5053165bc182020 Update .gitignore\ne7b78b592a8000d3a647de3a265c69496adebfe5 Update .gitignore\nfdd923ad2b522d6e4357229ea801d23ec5b16717 update readme\n7e14559d7f7e8676d557c9b73fc43fb3a66a0c3c added sticker\n493609efa7ce659ebebf5a0d0300f23788397e68 Initial commit\n\n\n\n\n\n3.5.8 Undo a commit\nWhen shit hits the fan, we can always undo a commit. For example, the following command reverts all changes to the inital commit\n\n% git reset --hard 493609e \nHEAD is now at 493609e Initial commit\n\nWe are now back at the first commit in the project.\n\n\n3.5.9 Undo undoing a commit\nTo properly do this without making mistakes, it is best to study the history of the HEAD\n\n% git reflog \n493609e (HEAD -> Wk4_markup) HEAD@{0}: reset: moving to 493609e\n9e6c38c HEAD@{1}: commit (amend): add two text files\n8d30c46 HEAD@{2}: commit: add text file\n21a3b5a (old-state) HEAD@{3}: checkout: moving from Exercise_wk4 to Wk4_markup\n176137b (origin/master, origin/HEAD, origin/Exercise_wk4, master, Exercise_wk4) HEAD@{4}: checkout: moving from Exercise_wk4 to Exercise_wk4\n176137b (origin/master, origin/HEAD, origin/Exercise_wk4, master, Exercise_wk4) HEAD@{5}: checkout: moving from old-state to Exercise_wk4\n21a3b5a (old-state) HEAD@{6}: checkout: moving from Exercise_wk4 to old-state\n176137b (origin/master, origin/HEAD, origin/Exercise_wk4, master, Exercise_wk4) HEAD@{7}: checkout: moving from 21a3b5ac1535703f4ce0d6feb2ccf3703f95eee3 to Exercise_wk4\n21a3b5a (old-state) HEAD@{8}: checkout: moving from Exercise_wk4 to 21a3b5a\n176137b (origin/master, origin/HEAD, origin/Exercise_wk4, master, Exercise_wk4) HEAD@{9}: checkout: moving from 21a3b5ac1535703f4ce0d6feb2ccf3703f95eee3 to Exercise_wk4\n21a3b5a (old-state) HEAD@{10}: checkout: moving from Exercise_wk4 to 21a3b\n176137b (origin/master, origin/HEAD, origin/Exercise_wk4, master, Exercise_wk4) HEAD@{11}: checkout: moving from 21a3b5ac1535703f4ce0d6feb2ccf3703f95eee3 to Exercise_wk4\n21a3b5a (old-state) HEAD@{12}: checkout: moving from Exercise_wk4 to 21a3b5a\n176137b (origin/master, origin/HEAD, origin/Exercise_wk4, master, Exercise_wk4) HEAD@{13}: checkout: moving from master to Exercise_wk4\n176137b (origin/master, origin/HEAD, origin/Exercise_wk4, master, Exercise_wk4) HEAD@{14}: checkout: moving from Exercise_wk4 to master\n176137b (origin/master, origin/HEAD, origin/Exercise_wk4, master, Exercise_wk4) HEAD@{15}: checkout: moving from Exercise_wk4 to Exercise_wk4\n176137b (origin/master, origin/HEAD, origin/Exercise_wk4, master, Exercise_wk4) HEAD@{16}: checkout: moving from master to Exercise_wk4\n176137b (origin/master, origin/HEAD, origin/Exercise_wk4, master, Exercise_wk4) HEAD@{17}: checkout: moving from SofieIssue to master\n1f488c6 (SofieIssue) HEAD@{18}: commit: remove pipe operator\n4ead406 HEAD@{19}: commit: update readme.md\n\nWe are now looking at the reflog - the log of where the HEAD has been. It used to be at\n\n9e6c38c HEAD@{1}: commit (amend): add two text files\n\nbut is now at\n\n493609e (HEAD -> Wk4_markup) HEAD@{0}: reset: moving to 493609e\n\nWe can use this history of where the head has been to go back to the previous step. In other words, if we would like to undo a commit, we can always go back to the previous HEAD stage –> the HEAD has been moved one step forward by the commit. Likewise, if we would like to undo a hard reset, we can also go back to the previous HEAD stage –> the HEAD has been moved one step forward by the reset.\nTo undo it all, we can use the indicator that is referenced by the reflog:\n\n% git reset --hard HEAD@{1}\nHEAD is now at 9e6c38c add two text files\n\nUsing reflog and HEAD is in this case more flexible than using log and the SHA-1 hash. reflog yields the log of all changes in the pointer HEAD, while log only gives you the history of the logged commits. Once a commit is undone, it is gone from the log. Moreover, using reflog and HEAD allows you to go back into the future, like in the above example.\nNOTE: Do not wait too long to undo your resets. After a few days/weeks garbage collection may kick in and Git will eventually see old commit as unreferenced. This makes them irretrievable\n\n\n\n3.5.10 Redo a commit\nA hard reset brings you back to a previous state. It loses all changes that have been committed since. If you’d like to undo a single commit and erase the commit message, but not throw out the modifications:\n\ngit reset --soft 493609e \n\nWe are now back at the initial commit, but all changes since have been staged. We can commit these changes as\n\n% git commit -a -m 'everything in a single commit'\n[Wk4_markup 525efa5] everything in a single commit\n 7 files changed, 36 insertions(+), 1 deletion(-)\n create mode 100644 Gerko/Assignment 1/Vink.jpg\n create mode 100644 Gerko/Assignment 1/Vink.pdf\n create mode 100644 README.Rmd\n create mode 100644 add_text_file.txt\n create mode 100644 markup_sticker_SMALL.png\n\nIf we study the log, we find that there are now only two commits.\n\n% git log --pretty=oneline \n5fe2c1bd44b1dbc92172b85dec3d87ced7073deb (HEAD -> Wk4_markup) everything in a single commit\n493609efa7ce659ebebf5a0d0300f23788397e68 Initial commit\n\n\n\n\n3.5.11 Merging branches\nLet’s see if we can merge the Wk4_markup branch into the Exercise_wk4 branch.\nFirst we need to checkout the branch we would like to merge into:\n\n% git checkout Exercise_wk4\nUpdating files: 100% (174/174), done.\nSwitched to branch 'Exercise_wk4'\nYour branch is up to date with 'origin/Exercise_wk4'.\n\nThen we can attempt to merge:\n\n% git merge Wk4_markup \nAuto-merging README.md\nCONFLICT (content): Merge conflict in README.md\nCONFLICT (add/add): Merge conflict in README.Rmd\nAuto-merging README.Rmd\nAutomatic merge failed; fix conflicts and then commit the result.\n\nWe’ve now effectively created a conflict. A conflict must be resolved before a merge is possible. If you switch to GiHub desktop, you’ll see this pop-up\n\nYou can use the drop-down menu to choose either modified file version as the one to keep after merging (which means you’ll throw out the other version from the other branch)\n\nThere is also the option to open the file in the editor and manually resolve the conflict.\n\nWe now see the detail about this conflict. Remember that we took an old state as our point of departure? After that point I have changed the header of the Readme.Rmd file. This conflict needs to be resolved before we can merge these branches.\n\n\n3.5.11.1 Resolve the conflict\nChoose Wk4_markup as the reference. Throw out the version from Exercise_wk4. You can do this manually or by choosing the following drop-down item in GitHub Desktop:\n\nAfter that, we can stage the changes and commit them in the Exercise_wk4 branch:\n\n% git add -A\n% git commit -m 'conflict resolved'\n\n\n\n\n\n3.5.12 Hand in your exercise\n\nTake the merged Exercise_wk4 branch as your point of departure\nCreate a new branch named Wk3_yourname\nChange the filename of the text file to yourname.txt\nStage the changes\nCommit the changes with a custom message\nPublish your branch on GitHub\nDo a pull request that can be automatically merged.\nPost an issue in this year’s repo, wherin you properly reference your PR to the old course repo.\n\n\n\n\n3.5.13 Solution\n\n% git branch Wk4_gerkovink \n% git checkout Wk4_gerkovink\nSwitched to branch 'Wk4_gerkovink'\n% mv add_text_file.txt gerkovink.txt\n% git add -A\n% git commit -m 'gerko`s commit' \n[Wk4_gerkovink fb26e75] gerko`s commit\n 1 file changed, 0 insertions(+), 0 deletions(-)\n rename add_text_file.txt => gerkovink.txt (100%)\n% git push origin Wk4_gerkovink\nEnumerating objects: 15, done.\nCounting objects: 100% (15/15), done.\nDelta compression using up to 8 threads\nCompressing objects: 100% (10/10), done.\nWriting objects: 100% (10/10), 1002 bytes | 1002.00 KiB/s, done.\nTotal 10 (delta 7), reused 0 (delta 0)\nremote: Resolving deltas: 100% (7/7), completed with 3 local objects.\nremote: \nremote: Create a pull request for 'Wk4_gerkovink' on GitHub by visiting:\nremote: https://github.com/gerkovink/markup2020/pull/new/Wk4_gerkovink\nremote: \nTo https://github.com/gerkovink/markup2020.git\n * [new branch] Wk4_gerkovink -> Wk4_gerkovink", + "section": "3.6 Exercise 2: Git it done", + "text": "3.6 Exercise 2: Git it done\nThis week we will also learn how to use \\(git\\) properly when we mess up. But let’s not learn that on this year’s repo ;-). Fork [this older course repository (https://github.com/gerkovink/markup2020), deselect! Copy the master branch only in order to copy all branches and checkout the Exercise_wk4 branch.\nLet’s continue this week with this second exercise.\n\n\n3.6.1 Disclaimer\nI’ll take you by the hand through the exercise. So if you follow this manual step by step, you’ll be done at the end and you will have a good notion of troubleshooting with Git [or a reference thereof].\nThis exercise is a summary of important commands. A full and comprehensive overview can be found in the pro Git book.\nO, and we forgot to tell you: you’ll need the terminal for this exercise. You may use the one in RStudio, or the dedicated terminal on UNIX systems or the command prompt or Windows Terminal on Windows.\n\n\n\n3.6.2 Prepare\nBefore we continue it is good to all start from the point of departure.\n\nUse the terminal to navigate to the Git repository (the location of the git repo on your HDD)\nType git pull to make sure that you obtain the latest state from the remote on GitHub\n\n\n% git pull\nAlready up to date.\n\nDon’t type the %; that is just the command prompt indicator on my machine. Yours may be different, such as > or $. We see that Git reminds me that I already have the latest state. I am up to date.\n\nChange the branch to the Exercise_wk4 branch.\n\n\n% git checkout Exercise_wk4\nSwitched to branch 'Exercise_wk4'\nYour branch is up to date with 'origin/Exercise_wk4'.\n\nI’ve now been switched to the Exercise_wk4 branch. It is up to date with origin/Exercise_wk4, meaning that GitHub and my local copy are in sync. origin is a shorthand name for the remote repository that a project was originally cloned from. It is useful that origin is referenced instead of the original repo’s URL –> This makes referencing much more convenient.\n\n\n\n3.6.3 Inspect the current state\nMake sure you are in the Exercise_wk4 branch. Then Use git log --graph to inspect the current Git branch and its commits.\n\n% git log --graph \n* commit 176137b1667cc6903f7a9eead5723892ef1a77a7 (HEAD -> master, origin/master, origin/HEAD)\n|\\ Merge: 0e67723 c902093\n| | Author: Gerko Vink <g.vink@uu.nl>\n| | Date: Thu Oct 29 12:44:01 2020 +0100\n| | \n| | Merge pull request #38 from thomasjwise/wisedev\n| | \n| | Assignment 3 - Beamer PDF\n| | \n| | Well done ✅\n| | \n| * commit c9020931678d90d91cfe21778e6ce5b4943e46cb\n| | Author: Thomas Wise <48682160+thomasjwise@users.noreply.github.com>\n| | Date: Wed Oct 28 13:59:23 2020 +0100\n| | \n| | Assignment 3 - Beamer PDF\n| | \n* | commit 0e67723572744b769389f5b8883c9f1aa6a3b7dd\n|\\ \\ Merge: 4134b75 1f488c6\n| | | Author: Gerko Vink <g.vink@uu.nl>\n| | | Date: Thu Oct 29 11:27:16 2020 +0100\n| | | \n\nWe see information about the history that brought us to this point in time. We see commit messages, the author, the dates, the SHA-1 hash and the graph tree. We asked for the graph tree with --graph.\nYou can scroll up and down the graph. To exit the graph window, type q. For help, type h. To obtain a more condensed graph, use\n\n% git log --oneline --graph\n* 176137b (HEAD -> Exercise_wk4, origin/master, origin/HEAD, origin/Exercise_wk4, master) Merge pull request #38 from thomasjwise/wisedev\n|\\ \n| * c902093 Assignment 3 - Beamer PDF\n* | 0e67723 Merge pull request #39 from gerkovink/SofieIssue\n|\\ \\ \n| * | 1f488c6 (SofieIssue) remove pipe operator\n| * | 4ead406 update readme.md\n|/ / \n* | 4134b75 Merge pull request #37 from pietjonker/piet\n|\\ \\ \n| * | f50014b commit assignment 2\n| * | 5ae2b9b Assignment 1 and 2\n* | | f277a35 Merge pull request #35 from zoedunias/zoedev\n|\\ \\ \\ \n| * | | 1c9aad6 Added Exercise 2\n* | | | 43fb1ed Merge pull request #34 from RianneKraakman/riannedev\n|\\ \\ \\ \\ \n| * | | | 75d9293 Add assignment 2\n* | | | | d3df110 Merge pull request #33 from gerkovink/gerkodev\n|\\ \\ \\ \\ \\ \n| * \\ \\ \\ \\ 34954f8 (origin/gerkodev, gerkodev) Merge pull request #22 from Goorbergh/ruben_assignment_1\n\nThis graph view is much more condensed. The nice thing about this view is the direct depiction of each action’s abbreviated SHA-1 key.\nWe can use the SHA-1 keys to instruct Git. For example, to obtain the history on commit c902093, we only need to refer the SHA-1 hash.\n\n% git log c902093 \ncommit c9020931678d90d91cfe21778e6ce5b4943e46cb\nAuthor: Thomas Wise <48682160+thomasjwise@users.noreply.github.com>\nDate: Wed Oct 28 13:59:23 2020 +0100\n\n Assignment 3 - Beamer PDF\n\ncommit db649539738bb30b63d93053b67891ef6c55037e\nAuthor: Thomas Wise <48682160+thomasjwise@users.noreply.github.com>\nDate: Wed Sep 16 14:04:21 2020 +0200\n\n Assignment 1\n\ncommit 21a3b5ac1535703f4ce0d6feb2ccf3703f95eee3\nMerge: 7f0806b f4a11cb\nAuthor: Gerko Vink <g.vink@uu.nl>\nDate: Tue Sep 15 20:15:25 2020 +0200\n\n Merge pull request #2 from gerkovink/gerkodev\n \n This image is too large\n\ncommit f4a11cbed729bc8454c01866aab4291b3b580d6f\nAuthor: Gerko Vink <g.vink@uu.nl>\n\nOr, a more condensed version of the same\n\n% git log c902093 --pretty=oneline\nc9020931678d90d91cfe21778e6ce5b4943e46cb Assignment 3 - Beamer PDF\ndb649539738bb30b63d93053b67891ef6c55037e Assignment 1\n21a3b5ac1535703f4ce0d6feb2ccf3703f95eee3 Merge pull request #2 from gerkovink/gerkodev\nf4a11cbed729bc8454c01866aab4291b3b580d6f resize image\n7f0806b68387d4f3c8af5c1f27d94b69e90a2d13 Merge pull request #1 from gerkovink/gerkodev\na36ed81b3831e6084c2adf661dc4cfb32c4cb5f7 add childhood memory\n9ba9c43437a7f00f5095df55db0c07d7233ad152 Add CV\n9bf1c32ea55b60bce613d65765c18deb522772ff Update .gitignore\n18761716665262f19296fb5d8e7c1720c8cea58a Merge branch 'master' of https://github.com/gerkovink/markup2020\n1ee60aa26142b5f175928d409614b8de84c1ef79 Update .gitignore\n7c3d816264b5629e7bfe112954178648d94a37b4 Delete markup_sticker_SMALL.psd\n37c356ca51b4ed03e96570934f28caf5fcfd75d8 Delete .DS_Store\nd56dd90172d1106117d53102e5053165bc182020 Update .gitignore\ne7b78b592a8000d3a647de3a265c69496adebfe5 Update .gitignore\nfdd923ad2b522d6e4357229ea801d23ec5b16717 update readme\n7e14559d7f7e8676d557c9b73fc43fb3a66a0c3c added sticker\n493609efa7ce659ebebf5a0d0300f23788397e68 Initial commit\n\nPlease note that we only reference the short hash. There is no need to reference the longer hash as long as the sequence of the shorter reference is unique.\nFrom this --pretty=oneline view it is now easy to spot the origin of our course repository - the initial commit that initiated the Git goodness. You can also see that I updated the .gitignore, a hidden file that specifies which files and directories to be ignored by Git. And I did some cosmetic changes and file deletions. This is very insightfull because of the detailed, but consice commit messages.\n\n\n\n3.6.4 Checkout an old state\nGo back in time to 21a3b5ac1535703f4ce0d6feb2ccf3703f95eee3 Merge pull request #2 from gerkovink/gerkodev.\nTo do so, we only need to refer the start of the SHA-1 key.\n\n% git checkout 21a3b5a\nNote: switching to '21a3b5a'.\n\nYou are in 'detached HEAD' state. You can look around, make experimental\nchanges and commit them, and you can discard any commits you make in this\nstate without impacting any branches by switching back to a branch.\n\nIf you want to create a new branch to retain commits you create, you may\ndo so (now or later) by using -c with the switch command. Example:\n\n git switch -c <new-branch-name>\n\nOr undo this operation with:\n\n git switch -\n\nTurn off this advice by setting config variable advice.detachedHead to false\n\nHEAD is now at 21a3b5a Merge pull request #2 from gerkovink/gerkodev\n\nWe are now at the old state. So we went back in time. The current state where we are is independent from all later commits, but is built exactly on all preceding commits as per the tree.\nThere are a couple of terms that are new:\n\nHEAD: The HEAD in Git is the pointer to the current branch reference. It is the last commit you have made or checked out [in our case]. REMEMBER that the head will always serve as the parent to the next commit\ndetached HEAD: The same as the head, but now the pointer references a specific commit and not a branch.\n\n\n\n3.6.4.1 The problem with a detached HEAD\nThis webpage illustrates the dangers of committing changes under a detached head quite nicely:\n\nThe HEAD pointer in Git determines your current working revision (and thereby the files that are placed in your project’s working directory). Normally, when checking out a proper branch name, Git automatically moves the HEAD pointer along when you create a new commit. You are automatically on the newest commit of the chosen branch. When you instead choose to check out a commit hash, Git won’t do this for you. The consequence is that when you make changes and commit them, these changes do NOT belong to any branch. This means they can easily get lost once you check out a different revision or branch: not being recorded in the context of a branch, you lack the possibility to access that state easily (unless you have a brilliant memory and can remember the commit hash of that new commit…).\n\nThe useful thing about going to an old commit is that you can take this state as a point of departure. Just beware of the pitfalls of working under a detached HEAD.\n\n\n\n3.6.4.2 leave the detached HEAD\nGo back to the branch HEAD\n\n% git switch - \nPrevious HEAD position was 21a3b5a Merge pull request #2 from gerkovink/gerkodev\nSwitched to branch 'Exercise_wk4'\nYour branch is up to date with 'origin/Exercise_wk4'.\n\n\n\n\n\n3.6.5 Make a new branch of the old state\nLet’s take that old state and make it into a proper point of departure for new things. Again, reference 21a3b5ac1535703f4ce0d6feb2ccf3703f95eee3 Merge pull request #2 from gerkovink/gerkodev, but now we make the state of 21a3b5a into a new branch. We call that branch Wk4_markup:\n\n% git checkout -b Wk4_markup 21a3b5a \nSwitched to a new branch 'Wk4_markup'\n\nWe now have checked out an old state and made it into a new branch. The cool thing is that we can now commit all we want and everything will be properly logged. Just remember that if you’d like to go back in time and play around with an old state of your project –> Merge the old state into a new branch like I demonstrated above.\n\n\n\n3.6.6 Add a new commit\nWe start by creating an empty text file\n\n% touch add_text_file.txt\n\nIf the touch command does not work on your machine, you may also create this file by hand. In a Windows-terminal, you can also use the command:\n\nPS C:\\GitHub\\Markup2020> New-Item .\\add_text_file.txt -type file\n\nNow, if we would like to commit the addition of this file to our repo, we get the following:\n\n% git commit -a -m 'add text file'\nOn branch Wk4_markup\nUntracked files:\n add_text_file.txt\n\nnothing added to commit but untracked files present\n\nThe commit was not succesfull, because the file add_text_file.txt is not yet tracked. Note that I use -a to specify to commit all changed files and folders that are tracked. I use -m to indicate that I would like to add the message add text file.\nYou see that using a GUI to Git like GitHub desktop or RStudio is quite convenient if you would not like to indicate which files to track. It is also less flexible.\n\n\n3.6.6.1 Add files to tracking\nTo track all untracked files and folders\n\ngit add -A\n\n\n\n\n3.6.6.2 commit with a message\nNow if we revisit the commit command\n\n% git commit -a -m 'add text file'\n[Wk4_markup 8d30c46] add text file\n 1 file changed, 0 insertions(+), 0 deletions(-)\n create mode 100644 add_text_file.txt\n\n\n\n\n\n3.6.7 Study the log again\n\n% git log --pretty=oneline\n8d30c4698b9761d650de2f5288389257762753ce (HEAD -> Wk4_markup) add text file\n21a3b5ac1535703f4ce0d6feb2ccf3703f95eee3 (old-state) Merge pull request #2 from gerkovink/gerkodev\nf4a11cbed729bc8454c01866aab4291b3b580d6f resize image\n7f0806b68387d4f3c8af5c1f27d94b69e90a2d13 Merge pull request #1 from gerkovink/gerkodev\na36ed81b3831e6084c2adf661dc4cfb32c4cb5f7 add childhood memory\n9ba9c43437a7f00f5095df55db0c07d7233ad152 Add CV\n9bf1c32ea55b60bce613d65765c18deb522772ff Update .gitignore\n18761716665262f19296fb5d8e7c1720c8cea58a Merge branch 'master' of https://github.com/gerkovink/markup2020\n1ee60aa26142b5f175928d409614b8de84c1ef79 Update .gitignore\n7c3d816264b5629e7bfe112954178648d94a37b4 Delete markup_sticker_SMALL.psd\n37c356ca51b4ed03e96570934f28caf5fcfd75d8 Delete .DS_Store\nd56dd90172d1106117d53102e5053165bc182020 Update .gitignore\ne7b78b592a8000d3a647de3a265c69496adebfe5 Update .gitignore\nfdd923ad2b522d6e4357229ea801d23ec5b16717 update readme\n7e14559d7f7e8676d557c9b73fc43fb3a66a0c3c added sticker\n493609efa7ce659ebebf5a0d0300f23788397e68 Initial commit\n\nWe can see that the HEAD is now at the latest commit and that this commit comes after the old-state from which we created the branch.\n\n\n3.6.7.1 Now add another empty text file.\n\n% touch add_another_text_file.txt\n\nLet’s say that we rather would have included this file in the previous commit, we can achieve this by\n\n% git add -A\n% git commit --amend -m \"add two text files\"\n[Wk4_markup 9e6c38c] add two text files\n Date: Tue Nov 3 23:09:11 2020 +0100\n 1 file changed, 0 insertions(+), 0 deletions(-)\n create mode 100644 add_text_file.txt\n\nWe have effectively ammended the previous commit. We’ve also changed the commit message into add two text files:\n\n% git log --pretty=oneline\n9e6c38c2288f7e7fce75de3bd1ffb522de112a8b (HEAD -> Wk4_markup) add two text files\n21a3b5ac1535703f4ce0d6feb2ccf3703f95eee3 (old-state) Merge pull request #2 from gerkovink/gerkodev\nf4a11cbed729bc8454c01866aab4291b3b580d6f resize image\n7f0806b68387d4f3c8af5c1f27d94b69e90a2d13 Merge pull request #1 from gerkovink/gerkodev\na36ed81b3831e6084c2adf661dc4cfb32c4cb5f7 add childhood memory\n9ba9c43437a7f00f5095df55db0c07d7233ad152 Add CV\n9bf1c32ea55b60bce613d65765c18deb522772ff Update .gitignore\n18761716665262f19296fb5d8e7c1720c8cea58a Merge branch 'master' of https://github.com/gerkovink/markup2020\n1ee60aa26142b5f175928d409614b8de84c1ef79 Update .gitignore\n7c3d816264b5629e7bfe112954178648d94a37b4 Delete markup_sticker_SMALL.psd\n37c356ca51b4ed03e96570934f28caf5fcfd75d8 Delete .DS_Store\nd56dd90172d1106117d53102e5053165bc182020 Update .gitignore\ne7b78b592a8000d3a647de3a265c69496adebfe5 Update .gitignore\nfdd923ad2b522d6e4357229ea801d23ec5b16717 update readme\n7e14559d7f7e8676d557c9b73fc43fb3a66a0c3c added sticker\n493609efa7ce659ebebf5a0d0300f23788397e68 Initial commit\n\n\n\n\n\n3.6.8 Undo a commit\nWhen shit hits the fan, we can always undo a commit. For example, the following command reverts all changes to the inital commit\n\n% git reset --hard 493609e \nHEAD is now at 493609e Initial commit\n\nWe are now back at the first commit in the project.\n\n\n3.6.9 Undo undoing a commit\nTo properly do this without making mistakes, it is best to study the history of the HEAD\n\n% git reflog \n493609e (HEAD -> Wk4_markup) HEAD@{0}: reset: moving to 493609e\n9e6c38c HEAD@{1}: commit (amend): add two text files\n8d30c46 HEAD@{2}: commit: add text file\n21a3b5a (old-state) HEAD@{3}: checkout: moving from Exercise_wk4 to Wk4_markup\n176137b (origin/master, origin/HEAD, origin/Exercise_wk4, master, Exercise_wk4) HEAD@{4}: checkout: moving from Exercise_wk4 to Exercise_wk4\n176137b (origin/master, origin/HEAD, origin/Exercise_wk4, master, Exercise_wk4) HEAD@{5}: checkout: moving from old-state to Exercise_wk4\n21a3b5a (old-state) HEAD@{6}: checkout: moving from Exercise_wk4 to old-state\n176137b (origin/master, origin/HEAD, origin/Exercise_wk4, master, Exercise_wk4) HEAD@{7}: checkout: moving from 21a3b5ac1535703f4ce0d6feb2ccf3703f95eee3 to Exercise_wk4\n21a3b5a (old-state) HEAD@{8}: checkout: moving from Exercise_wk4 to 21a3b5a\n176137b (origin/master, origin/HEAD, origin/Exercise_wk4, master, Exercise_wk4) HEAD@{9}: checkout: moving from 21a3b5ac1535703f4ce0d6feb2ccf3703f95eee3 to Exercise_wk4\n21a3b5a (old-state) HEAD@{10}: checkout: moving from Exercise_wk4 to 21a3b\n176137b (origin/master, origin/HEAD, origin/Exercise_wk4, master, Exercise_wk4) HEAD@{11}: checkout: moving from 21a3b5ac1535703f4ce0d6feb2ccf3703f95eee3 to Exercise_wk4\n21a3b5a (old-state) HEAD@{12}: checkout: moving from Exercise_wk4 to 21a3b5a\n176137b (origin/master, origin/HEAD, origin/Exercise_wk4, master, Exercise_wk4) HEAD@{13}: checkout: moving from master to Exercise_wk4\n176137b (origin/master, origin/HEAD, origin/Exercise_wk4, master, Exercise_wk4) HEAD@{14}: checkout: moving from Exercise_wk4 to master\n176137b (origin/master, origin/HEAD, origin/Exercise_wk4, master, Exercise_wk4) HEAD@{15}: checkout: moving from Exercise_wk4 to Exercise_wk4\n176137b (origin/master, origin/HEAD, origin/Exercise_wk4, master, Exercise_wk4) HEAD@{16}: checkout: moving from master to Exercise_wk4\n176137b (origin/master, origin/HEAD, origin/Exercise_wk4, master, Exercise_wk4) HEAD@{17}: checkout: moving from SofieIssue to master\n1f488c6 (SofieIssue) HEAD@{18}: commit: remove pipe operator\n4ead406 HEAD@{19}: commit: update readme.md\n\nWe are now looking at the reflog - the log of where the HEAD has been. It used to be at\n\n9e6c38c HEAD@{1}: commit (amend): add two text files\n\nbut is now at\n\n493609e (HEAD -> Wk4_markup) HEAD@{0}: reset: moving to 493609e\n\nWe can use this history of where the head has been to go back to the previous step. In other words, if we would like to undo a commit, we can always go back to the previous HEAD stage –> the HEAD has been moved one step forward by the commit. Likewise, if we would like to undo a hard reset, we can also go back to the previous HEAD stage –> the HEAD has been moved one step forward by the reset.\nTo undo it all, we can use the indicator that is referenced by the reflog:\n\n% git reset --hard HEAD@{1}\nHEAD is now at 9e6c38c add two text files\n\nUsing reflog and HEAD is in this case more flexible than using log and the SHA-1 hash. reflog yields the log of all changes in the pointer HEAD, while log only gives you the history of the logged commits. Once a commit is undone, it is gone from the log. Moreover, using reflog and HEAD allows you to go back into the future, like in the above example.\nNOTE: Do not wait too long to undo your resets. After a few days/weeks garbage collection may kick in and Git will eventually see old commit as unreferenced. This makes them irretrievable\n\n\n\n3.6.10 Redo a commit\nA hard reset brings you back to a previous state. It loses all changes that have been committed since. If you’d like to undo a single commit and erase the commit message, but not throw out the modifications:\n\ngit reset --soft 493609e \n\nWe are now back at the initial commit, but all changes since have been staged. We can commit these changes as\n\n% git commit -a -m 'everything in a single commit'\n[Wk4_markup 525efa5] everything in a single commit\n 7 files changed, 36 insertions(+), 1 deletion(-)\n create mode 100644 Gerko/Assignment 1/Vink.jpg\n create mode 100644 Gerko/Assignment 1/Vink.pdf\n create mode 100644 README.Rmd\n create mode 100644 add_text_file.txt\n create mode 100644 markup_sticker_SMALL.png\n\nIf we study the log, we find that there are now only two commits.\n\n% git log --pretty=oneline \n5fe2c1bd44b1dbc92172b85dec3d87ced7073deb (HEAD -> Wk4_markup) everything in a single commit\n493609efa7ce659ebebf5a0d0300f23788397e68 Initial commit\n\n\n\n\n3.6.11 Merging branches\nLet’s see if we can merge the Wk4_markup branch into the Exercise_wk4 branch.\nFirst we need to checkout the branch we would like to merge into:\n\n% git checkout Exercise_wk4\nUpdating files: 100% (174/174), done.\nSwitched to branch 'Exercise_wk4'\nYour branch is up to date with 'origin/Exercise_wk4'.\n\nThen we can attempt to merge:\n\n% git merge Wk4_markup \nAuto-merging README.md\nCONFLICT (content): Merge conflict in README.md\nCONFLICT (add/add): Merge conflict in README.Rmd\nAuto-merging README.Rmd\nAutomatic merge failed; fix conflicts and then commit the result.\n\nWe’ve now effectively created a conflict. A conflict must be resolved before a merge is possible. If you switch to GiHub desktop, you’ll see this pop-up\n\nYou can use the drop-down menu to choose either modified file version as the one to keep after merging (which means you’ll throw out the other version from the other branch)\n\nThere is also the option to open the file in the editor and manually resolve the conflict.\n\nWe now see the detail about this conflict. Remember that we took an old state as our point of departure? After that point I have changed the header of the Readme.Rmd file. This conflict needs to be resolved before we can merge these branches.\n\n\n3.6.11.1 Resolve the conflict\nChoose Wk4_markup as the reference. Throw out the version from Exercise_wk4. You can do this manually or by choosing the following drop-down item in GitHub Desktop:\n\nAfter that, we can stage the changes and commit them in the Exercise_wk4 branch:\n\n% git add -A\n% git commit -m 'conflict resolved'\n\n\n\n\n\n3.6.12 Hand in your exercise\n\nTake the merged Exercise_wk4 branch as your point of departure\nCreate a new branch named Wk3_yourname\nChange the filename of the text file to yourname.txt\nStage the changes\nCommit the changes with a custom message\nPublish your branch on GitHub\nDo a pull request that can be automatically merged.\nPost an issue in your forked template (remember Section 1), wherin you properly reference your PR to the old course repo.\n\nYou should now have all the skills to fill your template with the course deliverables and exercises. Now would be a good time to update your deliverables repository. If you have any questions, please post them as an issue to the course repository.\n\n\n\n3.6.13 Solution\n\n% git branch Wk4_gerkovink \n% git checkout Wk4_gerkovink\nSwitched to branch 'Wk4_gerkovink'\n% mv add_text_file.txt gerkovink.txt\n% git add -A\n% git commit -m 'gerko`s commit' \n[Wk4_gerkovink fb26e75] gerko`s commit\n 1 file changed, 0 insertions(+), 0 deletions(-)\n rename add_text_file.txt => gerkovink.txt (100%)\n% git push origin Wk4_gerkovink\nEnumerating objects: 15, done.\nCounting objects: 100% (15/15), done.\nDelta compression using up to 8 threads\nCompressing objects: 100% (10/10), done.\nWriting objects: 100% (10/10), 1002 bytes | 1002.00 KiB/s, done.\nTotal 10 (delta 7), reused 0 (delta 0)\nremote: Resolving deltas: 100% (7/7), completed with 3 local objects.\nremote: \nremote: Create a pull request for 'Wk4_gerkovink' on GitHub by visiting:\nremote: https://github.com/gerkovink/markup2020/pull/new/Wk4_gerkovink\nremote: \nTo https://github.com/gerkovink/markup2020.git\n * [new branch] Wk4_gerkovink -> Wk4_gerkovink", "crumbs": [ "3  Version Control" ] @@ -304,7 +314,7 @@ "href": "story.html", "title": "Contributors", "section": "", - "text": "The following story is written together with students from the course. The story is a work in progress and will be updated in current and future iterations of this course.\n\n… [add three more words here]\n\nHere is a list of contributors that helped to make this story possible.\n\nGerko Vink", + "text": "The following story is written together with students from the course. The story is a work in progress and will be updated in current and future iterations of this course.\n\nI opened the … [add three more words here]\n\nHere is a list of contributors that helped to make this story possible.\n\nGerko Vink\n[add your name here]", "crumbs": [ "Contributors" ] diff --git a/docs/story.html b/docs/story.html index 4c89eec..6ac1a08 100644 --- a/docs/story.html +++ b/docs/story.html @@ -194,10 +194,11 @@

Contributors

The following story is written together with students from the course. The story is a work in progress and will be updated in current and future iterations of this course.

-

… [add three more words here]

+

I opened the … [add three more words here]

Here is a list of contributors that helped to make this story possible.

diff --git a/story.qmd b/story.qmd index 2b92fb1..bd55d5a 100644 --- a/story.qmd +++ b/story.qmd @@ -4,11 +4,12 @@ The following story is written together with students from the course. The story --- -... [add three more words here] +I opened the ... [add three more words here] --- Here is a list of contributors that helped to make this story possible. +- [Gerko Vink](https:/wwww.github.com/gerkovink) - [add your name here] \ No newline at end of file