Fix presentation link

I don't think it needs its own slide now that I have introduced the
slide outlining the different types of reference

README.md

@@ -2,11 +2,15 @@
 
 This is a presentation about Git.
 
+## Download
+
+If you just want to download a copy of the presentation, you can do so [here](https://git.jonathanh.co.uk/attachments/b2f284a7-d9fe-4dda-b8e4-485d79cdfa6e).
+
 ## Build
 
 To build it, you will need make, pdflatex and ansi-to-svg and inkscape.
 
-To build the main pd, run:
+To build the main pdf, run:
 
 ```bash
 make main.pdf
@@ -26,7 +30,9 @@ make only-notes.pdf
 
 ## Auto Images
 
-The build system will generate certain types of graphics for the presentation as part of the build system. The resultant files will always go in the `auto-images` folder. As a result, this folder is not under version control.
+The build system will generate certain types of graphics for the presentation as part of the build
+system. The resultant files will always go in the `auto-images` folder. As a result, this folder is
+not under version control.
 
 In latex, all you need to do is
 
@@ -44,13 +50,16 @@ What is a presentation without an xkcd comic?
 \includegraphics[<options>]{auto-xkcd-<id>.png}
 ```
 
-If the above is included in the latex document, the XKCD comic with the specified ID will be downloaded and embedded in the pdf.
+If the above is included in the latex document, the XKCD comic with the specified ID will be
+downloaded and embedded in the pdf.
 
 ### Shell Output
 
-I am still not aware of aware of a reliable way to include ansi coloured shell output into a latex document. I also don't want to include loads of high-res screenshots in my Git repo.
+I am still not aware of aware of a reliable way to include ansi coloured shell output into a latex
+document. I also don't want to include loads of high-res screenshots in my Git repo.
 
-The work around I have come up with is to save the raw ansi output to a wile in `shell-output`. This normally involves forcing an application to output in colour:
+The work around I have come up with is to save the raw ansi output to a wile in `shell-output`. This
+normally involves forcing an application to output in colour:
 
 ```bash
 git -c color.status=always status > shell-output/git-status.out
@@ -63,3 +72,14 @@ git -c color.status=always status > shell-output/git-status.out
 ```
 
 The build system will convert the ansi output into an embeddable PDF that LaTeX will embed.
+
+### Online images
+
+In order to download an image from the internet and embed it in the presentation, you need do
+provide the extension and the base64 encoded URL.
+
+```latex
+\includegraphics[<options>]{auto-download-<base64 encodede url>.png}
+```
+
+

greeting.py

@@ -1,6 +1,25 @@
-import sys
-    def main():
-        print("Hello")
+#!/usr/bin/env python
 
-    if __name__ == "__main__":
-        main()
+import sys
+
+def cat():
+    print("Meow")
+
+def dog():
+    print("Woof")
+
+def cow():
+    print("Moo")
+
+def main():
+    if len(sys.argv) > 1 and sys.argv[1] == "cat":
+        cat()
+    elif len(sys.argv) > 1 and sys.argv[1] == "dog":
+        dog()
+    elif len(sys.argv) > 1 and sys.argv[1] == "cow":
+        cow()
+    else:
+        print("HELLO WORLD")
+
+if __name__ == "__main__":
+    main()

main.latex

@@ -1,4 +1,4 @@
-\documentclass{beamer}
+\documentclass[aspectratio=169]{beamer}
 
 \usepackage{pgfpages}
 %showNotes%\setbeameroption{show notes on second screen=right}
@@ -15,14 +15,13 @@
 \usepackage{amsmath}
 \usepackage{pdfpages}
 \usepackage{tikz}
+\usepackage[UKenglish]{babel}%
 \usetikzlibrary{shapes.geometric, arrows}
 \tikzstyle{commit} = [circle, text centered, line width=2,
 	minimum size=1.5cm, draw=blue, fill=blue!80, text=white]
 \tikzstyle{branch} = [ellipse, text centered, text=green]
 \tikzstyle{arrow} = [thick, <-, draw=blue]
 
-
-
 \usepackage{dirtree}
 \usepackage{csquotes}
 %\usepackage{gitdags}
@@ -35,7 +34,11 @@
 
 \usetheme{default}
 \beamertemplatenavigationsymbolsempty
-\hypersetup{pdfpagemode=UseNone} % don't show bookmarks on initial view
+\hypersetup{%
+	colorlinks=true,
+	urlcolor=blue,
+	%pdfpagemode=UseNone
+} % don't show bookmarks on initial view
 
 %\lstset{%
 %  breaklines=true,
@@ -57,37 +60,31 @@
 \author{Jonathan Hodgson (Archie)}
 \date{\today}
 
+%\titlegraphic{\includegraphics[width=1cm,keepaspectratio]{auto-xkcd-1597.png})
+ \institute{
+      \includegraphics[width=\textwidth,height=.5\textheight,keepaspectratio]{auto-xkcd-1597.png}%
+ }
 
 
 \begin{document}
 
-\frame{\titlepage}
-
-\note{%
-	A few people recently have asked me about Git.
-
-	Git has become the de-facto for most situations.
-
-	Microsoft recently moved to git for version controlling Windows and Office.
-
-	I will not be able to cover everything relating to Git, it is an incredibly powerful tool.
-	However, hopefully I will be able to give you enough to get started and at least understand the
-	official documentation.
-}
-
-\begin{frame}
-	\frametitle{Aims}
-	I am obviously not going to be able to go over everything that git does.
-	\begin{itemize}
-		\item I don't know everything Git does
-		\item Git does LOADS of stuff
-	\end{itemize}
-	Hopefully after this you will be able to use Git well for most day-to-day tasks. Git has very
-	compressive documentation. I hope that this will also give you enough of a background to
-	understand the documentation.
+\frame{
+	\titlepage
 	\note{%
+		A few people recently have asked me about Git.
+
+		Git has a reputation for being hard. I think this is (at least partly) because so much of
+		its inner workings are abstracted away making the interface feel like magic. Not to mention
+		videos with titles like "Learn git in 15 minutes"
+
+		I think that understanding a bit about how Git works under the hood will help de-mistily it.
+		It certainly did for me.
+
+		Git's data model is actually quite simple (beautiful even). Understanding the basics of this
+	can really help.
+
 	}
-\end{frame}
+}
 
 \begin{frame}
 	\frametitle{What is Git}
@@ -101,9 +98,9 @@
 	\end{itemize}
 
 	\note{%
-		Git is still being developed.
 
-		Being distributed means you can work on repositories offline (Unlike SVN).
+		It keeps track by maintaining a series of snapshots containing all of the files and folders
+		at each point.
 
 		It's useful even if you're working on things by your self. This presentation is version
 		controlled.
@@ -111,31 +108,147 @@
 		You can use it to find out when something broke. I won't be covering it today but there is a
 		tool called git bisect that can take a unit test (or script) to analyse when something broke
 		using a binary search.
+
+		Being distributed means you can work on repositories offline (Unlike SVN).
+	}
+\end{frame}
+
+\begin{frame}
+	\frametitle{What is Git}
+
+	\begin{center}
+		\Huge Git $\ne$ Github
+	\end{center}
+
+	\note{%
+		Although the names are similar, Git and Github are separate projects. Github is a Microsoft
+		owned, closed source company that is a remote repository for Git projects.
+		
+		There are others such as Bitbucket, Gitlab, Gitea
+	}
+\end{frame}
+
+\begin{frame}
+	\frametitle{Naïve Approach}
+	\begin{columns}
+		\begin{column}{0.5\textwidth}
+			\dirtree{%
+				.1 Project.
+				.2 draft.
+				.3 some.
+				.3 files.
+				.2 final-draft.
+				.3 some.
+				.3 files.
+				.2 final.
+				.3 some.
+				.3 files.
+			}
+		\end{column}
+		\begin{column}{0.5\textwidth}
+			\textbf{Pros}
+			\begin{itemize}
+				\item Simple
+				\item No dependencies
+				\item No Learning curve
+			\end{itemize}
+			\vspace{1em}
+			\textbf{Cons}
+			\begin{itemize}
+				\item Difficult to collaborate
+				\item Lot's of wasted disk space
+				\item Hard to find particular versions of files
+			\end{itemize}
+		\end{column}
+	\end{columns}
+	\note{%
+		There are many approaches you could take to version control
+
+		I think, being honest, we have all done this. This sort of works, if you're working on
+		something by yourself. Once you start collaborating on software, you are going to have a bad
+		time.
+
+		You could add time stamps and zip up changes when you need to collaborate.
+
+		Git has a well thought out model that allows us to address these problems.
+	}
+\end{frame}
+
+\begin{frame}
+	\frametitle{Files and Folders}
+
+	\textbf{Blob} In Git, a file is called a blob.
+
+	\textbf{Tree} In Git, a directory is called a tree.
+
+	
+	\note{%
+		Git needs a way of modeling files and folders in a file system independent way.
+
+		These concepts are pretty familiar. A tree can contain other trees or blobs.
+
+		At its core, Git is a content addressed storage tool. All files and folders are addressed by
+		a (hardened) sha1 hash.
+
 	}
 \end{frame}
 
 
 \begin{frame}
-\frametitle{Obligitary XKCD Comic}
+	\frametitle{Commits}
+	\framesubtitle{(Snapshots)}
 	\begin{center}
-		\includegraphics[width=\textwidth,height=0.8\textheight,keepaspectratio]{auto-xkcd-1597.png}
+		\begin{tikzpicture}
+		%\draw (-1.5,-1.5) rectangle (7.5,1.5);
+		%\node at (-2.5,0) {master};
+		\node[commit,minimum size=2cm] at (0,0) (commit1) {Draft};
+		\node[commit,minimum size=2cm] at (3,0) (commit2) {Final Draft};
+		\node[commit,minimum size=2cm,draw=red] at (6,0) (commit3) {Final};
+		\draw[arrow] (commit1) -- (commit2);
+		\draw[arrow] (commit2) -- (commit3);
+		\node[draw,text width=1.8cm,anchor=north,align=center] at (0, -1.5) {\small \vdots\\[0.1cm] };
+		\node[draw,text width=1.8cm,anchor=north,align=center] at (3, -1.5) {\small \vdots\\[0.1cm] Draft };
+		\node[draw,text width=1.8cm,anchor=north,align=center] at (6, -1.5) {\small \vdots\\[0.1cm] Final Draft };
+	\end{tikzpicture}
 	\end{center}
 	\note{%
-		I have done this
+		\begin{itemize}
+			\item We could then think of history as a linear series of snapshots.
+			\item Each circle here represents a snapshot.
+			\item The previous snapshot is referenced somewhere in each snapshot.
+			\item We then just need to record the most recent version somewhere.
+		\end{itemize}
+	}
+\end{frame}
 
-		Git has a reputation for being hard.
+\begin{frame}
+	\frametitle{Commits}
+	\begin{center}
+		\begin{tikzpicture}
+		%\draw (-1.5,-1.5) rectangle (7.5,1.5);
+		%\node at (-2.5,0) {master};
+		\node[commit] at (0,0) (commit1) {93e4d3d\ldots};
+		\node[commit] at (3,0) (commit2) {2557962\ldots};
+		\node[commit,draw=red] at (6,0) (commit3) {od68560\ldots};
+		\draw[arrow] (commit1) -- (commit2);
+		\draw[arrow] (commit2) -- (commit3);
+		\node[draw,text width=1.8cm,anchor=north,align=center] at (0, -1.5) {\small \vdots\\[0.1cm] };
+		\node[draw,text width=1.8cm,anchor=north,align=center] at (3, -1.5) {\small \vdots\\[0.1cm] 93e4d3d\ldots };
+		\node[draw,text width=1.8cm,anchor=north,align=center] at (6, -1.5) {\small \vdots\\[0.1cm] 2557962\ldots };
+	\end{tikzpicture}
+	\end{center}
+	\note{%
+		\begin{itemize}
+			\item Rather than human readable names, Git references each snapshot (called a commit)
+				by a cryptographic hash. Currently using a hardened sha1 but there is an effort to
+				move to sha256.
+			\item Similarly to the model above, each commit references the previous (except the
+				first obviously)
+			\item The commit also includes meta information such as the committer, a timestamp and a
+				message.
+			\item We will look at this in more detail a bit later.
+		\end{itemize}
 
-		It's interface abstracts away a lot of the work, meaning it's commands can feel like magic.
-		When it works, this is fine but unfortunately when things go wrong, you can be left - like
-		in this comic - with no idea how to proceed.
-
-		It's interface can be confusing, there are some commands that do a lot (checkout) and there
-		are often multiple ways to achieve something.
-
-		I think that understanding a bit about how Git works under the hood will help de-mistily it.
-
-		Git's data model is actually quite simple (beautiful even). Understanding the basics of this
-can really help.
 	}
 \end{frame}
 
@@ -159,7 +272,7 @@ can really help.
 		git --version
 	\end{minted}
 
-	\href{https://gitforwindows.org/}{Git for Windows: https://gitforwindows.org/}
+	Git for Windows: \href{https://gitforwindows.org/}{https://gitforwindows.org/}
 
 	\note{%
 		Git is probably already installed if you are on a Linux system. However, if not, it will
@@ -224,226 +337,6 @@ can really help.
 	}
 \end{frame}
 
-%\begin{frame}[fragile]
-%	\frametitle{Setting It Up}
-%	\framesubtitle{Preferences}
-%
-%	\textbf{Pick One}
-%	\begin{minted}{bash}
-%		# No colour
-%		git config --global color.ui never
-%
-%		# Auto colour
-%		git config --global color.ui auto
-%
-%		# Force colour
-%		git config --global color.ui always
-%
-%		# Overide for a command
-%		git -c color.ui=always status > ~/some-file
-%
-%	\end{minted}
-%	
-%	\note{%
-%		On Linux systems, this is set to auto by default. Might be different on a Mac. Generally
-%		auto is probably what you want. It will be coloured unless you are piping the output to a
-%		file or another process.
-%
-%		Take note of the incorrect spelling of colour.
-%
-%		You can override all configuration options on an individual command basis if you like.
-%	}
-%\end{frame}
-
-\begin{frame}
-	\frametitle{Terminology}
-	\framesubtitle{Objects}
-
-	\textbf{Blob} In Git, a file is called a blob.
-
-	\textbf{Tree} In Git, a directory is called a tree.
-
-	\textbf{Commit} A snapshot of your code
-
-	% All of these are referenced by a hash and stored in the \mintinline{bash}{.git/objects/}
-	% directory.
-	
-	\note{%
-		Technically, a blob is kind of like an inode on the file system so also represents symbolic
-		links.
-
-		There are some other types such as submodules but I won't be addressing them in this
-		presentation.
-	}
-\end{frame}
-
-
-\begin{frame}
-	\frametitle{Naïve Approach}
-	\begin{columns}
-		\begin{column}{0.5\textwidth}
-			\dirtree{%
-				.1 Project.
-				.2 draft.
-				.3 some.
-				.3 files.
-				.2 final-draft.
-				.3 some.
-				.3 files.
-				.2 final.
-				.3 some.
-				.3 files.
-				% .2 real-final.
-				% .3 some.
-				% .3 files.
-				% .2 actual-real-final.
-				% .3 some.
-				% .3 files.
-			}
-		\end{column}
-		\begin{column}{0.5\textwidth}
-			\textbf{Pros}
-			\begin{itemize}
-				\item Simple
-				\item No dependencies
-				\item No Learning curve
-			\end{itemize}
-			\vspace{1em}
-			\textbf{Cons}
-			\begin{itemize}
-				\item Difficult to collaborate
-				\item Lot's of wasted disk space
-				\item Can be difficult to work out chronological order
-			\end{itemize}
-		\end{column}
-	\end{columns}
-	\note{%
-		I think, being honest, we have all done this. This sort of works, if you're working on
-		something by yourself. Once you start collaborating on software, you are going to have a bad
-		time.
-
-		However, this is a simple approach and not a million miles from what Git does internally.
-	}
-\end{frame}
-
-\begin{frame}
-	\frametitle{Model it}
-	\begin{center}
-		\begin{tikzpicture}
-		%\draw (-1.5,-1.5) rectangle (7.5,1.5);
-		%\node at (-2.5,0) {master};
-		\node[commit,minimum size=2cm] at (0,0) (commit1) {Draft};
-		\node[commit,minimum size=2cm] at (3,0) (commit2) {Final Draft};
-		\node[commit,minimum size=2cm,draw=red] at (6,0) (commit3) {Final};
-		\draw[arrow] (commit1) -- (commit2);
-		\draw[arrow] (commit2) -- (commit3);
-		\node[draw,text width=1.8cm,anchor=north,align=center] at (0, -1.5) {\small \vdots\\[0.1cm] };
-		\node[draw,text width=1.8cm,anchor=north,align=center] at (3, -1.5) {\small \vdots\\[0.1cm] Draft };
-		\node[draw,text width=1.8cm,anchor=north,align=center] at (6, -1.5) {\small \vdots\\[0.1cm] Final Draft };
-	\end{tikzpicture}
-	\end{center}
-	\note{%
-		\begin{itemize}
-			\item This is a simple representation of the folder structure we saw.
-			\item Notice that so the computer knows the order, somewhere in each ``snapshot", we
-				include a reference to the previous snapshot.
-			\item We then just need to record the most recent version somewhere.
-		\end{itemize}
-	}
-\end{frame}
-
-
-
-\begin{frame}
-	\frametitle{Commits}
-	\begin{center}
-		\begin{tikzpicture}
-		%\draw (-1.5,-1.5) rectangle (7.5,1.5);
-		%\node at (-2.5,0) {master};
-		\node[commit] at (0,0) (commit1) {93e4d3d\ldots};
-		\node[commit] at (3,0) (commit2) {2557962\ldots};
-		\node[commit] at (6,0) (commit3) {od68560\ldots};
-		\draw[arrow] (commit1) -- (commit2);
-		\draw[arrow] (commit2) -- (commit3);
-		\node[draw,text width=1.8cm,anchor=north,align=center] at (0, -1.5) {\small \vdots\\[0.1cm] };
-		\node[draw,text width=1.8cm,anchor=north,align=center] at (3, -1.5) {\small \vdots\\[0.1cm] 93e4d3d\ldots };
-		\node[draw,text width=1.8cm,anchor=north,align=center] at (6, -1.5) {\small \vdots\\[0.1cm] 2557962\ldots };
-	\end{tikzpicture}
-	\end{center}
-	\note{%
-		\begin{itemize}
-			\item Rather than human readable names, Git references each snapshot (called a commit)
-				by a cryptographic hash. Currently using a hardened sha1 but there is an effort to
-				move to sha256.
-			\item Similarly to the model above, each commit references the previous (except the
-				first obviously)
-			\item The commit also includes meta information such as the committer, a timestamp and a
-				message.
-			\item We will look at this in more detail a bit later.
-		\end{itemize}
-
-	}
-\end{frame}
-
-\begin{frame}
-	\frametitle{Commits / Branches}
-	\begin{center}
-		\begin{tikzpicture}
-			%\draw (-1.5,-1.5) rectangle (7.5,1.5);
-			%\node at (-2.5,0) {master};
-			\node[commit] at (0,0) (commit1) {};
-			\node[commit] at (2,0) (commit2) {A};
-			\node[commit] at (4,0) (commit3) {B};
-			\node[commit] at (4,-2) (commit3b) {C};
-			\draw[arrow] (commit1) -- (commit2);
-			\draw[arrow] (commit2) -- (commit3);
-			\draw[arrow] (commit2) -- (commit3b);
-		\end{tikzpicture}
-	\end{center}
-	\note{%
-		The linear graph we just saw is an overly simplistic representation. In reality, Git
-		represents history using a Directed acyclic graph which allows parents to be shared my
-		multiple commits. This is useful because it allows for Branches. We will look at these a bit
-		more later.
-
-		It is good practice to develop features on a separate branch. This allows for multiple
-		people to work on a project as well as allowing things like bug-fixes to be deployed without
-		having to worry about interference from a new feature.
-	}
-\end{frame}
-
-\begin{frame}
-	\frametitle{Commits / Branches}
-	\begin{center}
-		\begin{tikzpicture}
-			%\draw (-1.5,-1.5) rectangle (7.5,1.5);
-			%\node at (-2.5,0) {master};
-			\node[commit] at (0,0) (commit1) {};
-			\node[commit] at (2,0) (commit2) {};
-			\node[commit] at (5,0) (commit4) {A};
-			\node[commit] at (8,0) (commit5) {C};
-			\node[commit] at (4,-2) (commit3b) {};
-			\node[commit] at (6,-2) (commit4b) {B};
-			\draw[arrow] (commit1) -- (commit2);
-			\draw[arrow] (commit2) -- (commit4);
-			\draw[arrow] (commit4) -- (commit5);
-			\draw[arrow] (commit2) -- (commit3b);
-			\draw[arrow] (commit3b) -- (commit4b);
-			\draw[arrow] (commit4b) -- (commit5);
-		\end{tikzpicture}
-	\end{center}
-	\note{%
-		As well as 2 commits' ability to share a parent, the opposite is also true, Here, we see
-		that a commit is able to have multiple parents.
-
-		This is called a merge commit - because it merges two branches. In a lot of situations git
-		is smart enough to auto-merge branches although at times human intervention is necessary.
-
-		By default, git creates a branch called Master when you create a repository.
-	}
-\end{frame}
-
-
 \begin{frame}
 	\frametitle{Create a repository}
 	\begin{center}
@@ -457,6 +350,19 @@ can really help.
 	}
 \end{frame}
 
+\begin{frame}
+	\frametitle{Create a repository}
+	\begin{center}
+		\includegraphics[width=\textwidth,height=0.8\textheight,keepaspectratio]{auto-shell-tree-empty-git.pdf}
+	\end{center}
+	\note{%
+		Do this in a live terminal. MAKE SURE YOU MAKE YOUR FONT BIGGER
+
+		Show that the \mintinline{bash}{.git} folder has been created and do a tree to show what is
+		in it.
+	}
+\end{frame}
+
 \begin{frame}[fragile]
 	\frametitle{Git status}
 	
@@ -471,6 +377,31 @@ can really help.
 	}
 \end{frame}
 
+\begin{frame}
+	\frametitle{Staging Area}
+	\begin{itemize}
+		\item Sometimes called the git index
+		\item An intermediate area in which you can pick files to be included in the next commit.
+		\item Also allows you to exclude some files from your version history.
+			\begin{itemize}
+				\item Log files
+				\item Binary files
+				\item Minified files
+			\end{itemize}
+	\end{itemize}
+	\note{%
+		This is the last thing before we start actually doing stuff (promise).
+
+		This is particularly useful if you have multiple logically unrelated changes and want to
+		make separate snapshots for each.
+
+		Also useful if when programming you write your tests along side your code, you would
+		normally want those to be separate snapshots.
+
+		We will talk about .gitignore later which is another way of ignoring files
+	}
+\end{frame}
+
 
 \begin{frame}[fragile]
 	\frametitle{Staging Area}
@@ -481,14 +412,6 @@ can really help.
 		git add -A
 	\end{minted}
 	\note{%
-		The staging area is where you put things that you want to be committed.
-
-		It can often be useful to manually split changes up into different commits. You might be
-		working on feature A and feature B simultaneously. It is good practice to have each feature
-		as a separate commit so you could add feature A to the staging area, commit it, then do the
-		same for feature B.
-
-		We will talk about \mintinline{bash}{.gitignore} in a bit.
 	}
 \end{frame}
 
@@ -505,11 +428,8 @@ can really help.
 	}
 \end{frame}
 
-\begin{frame}[fragile]
+\begin{frame}
 	\frametitle{Committing}
-	\begin{minted}{bash}
-		git commit
-	\end{minted}
 
 	\begin{itemize}
 		\item First line should be concise summary around 50 chars
@@ -537,6 +457,7 @@ can really help.
 	\framesubtitle{Commit early, commit often}
 	\begin{itemize}
 		\item Every time you complete a small change or fix a bug
+		\item For each point on a detailed to-do list
 		\item You don't normally want to commit broken code (intentionally at least)
 		\item In some instances you might want to auto-commit - but probably not too often.
 			\begin{itemize}
@@ -595,6 +516,8 @@ can really help.
 	\note{%
 		Diff is pretty smart. It will normally work for whatever combinations of commits, references
 		(more on that later) or files.
+
+		Change Hello to Hello World
 	}
 \end{frame}
 
@@ -675,6 +598,8 @@ can really help.
 	}
 \end{frame}
 
+
+
 \begin{frame}
 	\frametitle{References}
 		\begin{itemize}
@@ -685,8 +610,35 @@ can really help.
 		\end{itemize}
 	\note{%
 		We've seen a couple of these (sort of)
+	}
+\end{frame}
 
-		Master and Head
+\begin{frame}
+	\frametitle{References}
+	\begin{itemize}
+		\item Branches
+			\begin{itemize}
+				\item Parallel development
+			\end{itemize}
+		\item Tags
+			\begin{itemize}
+				\item Special points in history (Release versions)
+			\end{itemize}
+		\item HEAD
+			\begin{itemize}
+				\item Current position in history
+			\end{itemize}
+	\end{itemize}
+	\note{%
+		Branches allow for parallel development, individually or multiple people. We well look at
+		these in more detail in a minute.
+
+		Tags allow you to mark special commits. Normally this is used for release versions or
+		similar.
+
+		HEAD refers to the commit or branch you are currently looking at. We will see in a minute
+		that you can revert a whole project to a previous point in time. This is how git knows
+		where (when?) you are.
 	}
 \end{frame}
 
@@ -716,40 +668,105 @@ can really help.
 \end{frame}
 
 \begin{frame}
-	\frametitle{References}
-	\framesubtitle{HEAD}
-	\begin{itemize}
-		\item The HEAD references is directly in the \mintinline{bash}{.git} folder.
-		\item It refers to the ``current" commit. It is how git knows where you are.
-		\item This normally refers to a branch's head commit.
-		\item In some situations it will refer to a commit directly.
-	\end{itemize}
-	\note{%
-		Not sure why it is not in refs folder
-
-		If it refers directly to a commit, the repository is in what is called a ``detached head"
-		state.
-	}
-\end{frame}
-
-	
-\begin{frame}[fragile]
 	\frametitle{Branches}
 
 	\begin{itemize}
+		\item By default Git will create a branch called Master (maybe?).
 		\item Allows multiple features to be developed in parallel without interference.
 		\item Allows multiple people to collaborate easily.
 	\end{itemize}
 
+	\note{%
+		So, when I originally wrote this slide, git would create a branch called master by default.
+		The convention was that this was your "main" branch. Currently on my system it still does
+		although there is a movement to switch the default to main or primary or something similar.
+
+		I have no intentions to make this a political talk so make of it what you want.
+	}
+
+\end{frame}
+
+\begin{frame}
+	\frametitle{Commits / Branches}
+	\begin{center}
+		\begin{tikzpicture}
+			%\draw (-1.5,-1.5) rectangle (7.5,1.5);
+			%\node at (-2.5,0) {master};
+			\node[commit] at (0,0) (commit1) {};
+			\node[commit] at (2,0) (commit2) {A};
+			\node[commit] at (4,0) (commit3) {B};
+			\node[commit] at (4,-2) (commit3b) {C};
+			\node[anchor=west] at (4.5,0.5) {+Bugfix};
+			\node[anchor=west] at (4.5,-2.5) {+Feature};
+			\draw[arrow] (commit1) -- (commit2);
+			\draw[arrow] (commit2) -- (commit3);
+			\draw[arrow] (commit2) -- (commit3b);
+			\draw[draw=red] (-1,1) rectangle (6.5,-0.99);
+			\node[fill=red,text=white,anchor=north west] at (-1,1) {Branch 1};
+			\draw[draw=green] (-1,-1) rectangle (6.5,-3);
+			\node[fill=green,text=white,anchor=north west] at (-1,-1) {Branch 2};
+		\end{tikzpicture}
+	\end{center}
+	\note{%
+		The linear graph we just saw is an overly simplistic representation. In reality, Git
+		represents history using a Directed acyclic graph which allows parents to be shared my
+		multiple commits. This is useful because it allows for Branches.
+
+		It is good practice to develop features on a separate branch. This allows for multiple
+		people to work on a project as well as allowing things like bug-fixes to be deployed without
+		having to worry about interference from a new feature.
+	}
+\end{frame}
+
+\begin{frame}
+	\frametitle{Commits / Branches}
+	\begin{center}
+		\begin{tikzpicture}
+			%\draw (-1.5,-1.5) rectangle (7.5,1.5);
+			%\node at (-2.5,0) {master};
+			\node[commit] at (0,0) (commit1) {};
+			\node[commit] at (2,0) (commit2) {};
+			\node[commit] at (5,0) (commit4) {A};
+			\node[commit] at (8,0) (commit5) {C};
+			\node[commit] at (4,-2) (commit3b) {};
+			\node[commit] at (6,-2) (commit4b) {B};
+			\node[anchor=west] at (5.5,0.5) {+Bugfix};
+			\node[anchor=west] at (6.5,-2.5) {+Feature};
+			\node[anchor=south west] at (8.7,-0.2) {\parbox{\textwidth}{+Bugfix \\ +Feature}};
+			\draw[arrow] (commit1) -- (commit2);
+			\draw[arrow] (commit2) -- (commit4);
+			\draw[arrow] (commit4) -- (commit5);
+			\draw[arrow] (commit2) -- (commit3b);
+			\draw[arrow] (commit3b) -- (commit4b);
+			\draw[arrow] (commit4b) -- (commit5);
+			\draw[draw=red] (-1,1) rectangle (10.5,-0.99);
+			\node[fill=red,text=white,anchor=north west] at (-1,1) {Branch 1};
+			\draw[draw=green] (-1,-1) rectangle (10.5,-3);
+			\node[fill=green,text=white,anchor=north west] at (-1,-1) {Branch 2};
+		\end{tikzpicture}
+	\end{center}
+	\note{%
+		As well as 2 commits' ability to share a parent, the opposite is also true, Here, we see
+		that a commit is able to have multiple parents.
+
+		This is called a merge commit - because it merges two branches. In a lot of situations git
+		is smart enough to auto-merge branches although at times human intervention is necessary.
+	}
+\end{frame}
+	
+\begin{frame}[fragile]
 	\begin{minted}{bash}
 	# List Branches
 	git branch # -v adds more info
+
 	# Create a branch called test
 	git branch test # or
 	cp ~/.git/refs/heads/master ~/.git/refs/heads/test
+
 	# Switch to new branch
 	git switch test # or
 	git checkout test
+
 	# Create and switch in one go
 	git switch -c test # or
 	git checkout -b test
@@ -909,7 +926,6 @@ can really help.
 		\begin{itemize}
 			\item HTTP(S)
 			\item SSH
-			\item GIT
 			\item Local Filesystem
 		\end{itemize}
 	\end{itemize}
@@ -1038,45 +1054,65 @@ can really help.
 \end{frame}
 
 \begin{frame}
-	\frametitle{Useful supporting tools}
-	\framesubtitle{Bat}
-	\begin{center}
-		\includegraphics[width=\textwidth,height=0.8\textheight,keepaspectratio]{auto-download-aHR0cHM6Ly9jYW1vLmdpdGh1YnVzZXJjb250ZW50LmNvbS82N2U0NGY0YTY4MTUwMzI1Zjc0YjNhNDY4MjBiNzQ3M2ZmN2I5MWE2LzY4NzQ3NDcwNzMzYTJmMmY2OTJlNjk2ZDY3NzU3MjJlNjM2ZjZkMmYzMjZjNTM1NzM0NTI0NTJlNzA2ZTY3.png}
-	\end{center}
-	\href{https://github.com/sharkdp/bat}{https://github.com/sharkdp/bat}
+	\frametitle{Issues}
+	\begin{itemize}
+		\item Not part of Git, rather something most Git hosting providers offer.
+		\item You can normally reference issues in commit messages using \# symbol.
+	\end{itemize}
 	\note{%
-		Bat is described as cat with wings.
+		Demonstrate this in a browser using Github
+	}
 	
-		It adds syntax highlighting to files. Useful even if you're not using Git
+\end{frame}
 
-		As this is a git talk, it shows lines that have changed since the last commit
+\begin{frame}
+	\frametitle{Pull Requests}
+	\framesubtitle{Merge Requests}
+
+	\begin{enumerate}
+		\item Fork
+		\item Clone
+		\item Branch
+		\item Commit
+		\item Push
+	\end{enumerate}
+	
+	\note{%
+		\begin{itemize}
+			\item Not part of Git, rather something most Git hosting providers offer.
+			\item It allows for people to contribute code to repositories that they don't have
+				write access to
+		\end{itemize}
 	}
 \end{frame}
 
 \begin{frame}
 	\frametitle{Useful supporting tools}
-	\framesubtitle{RigGrep / Fd}
-	\href{https://github.com/sharkdp/fd}{https://github.com/sharkdp/fd}
+	\framesubtitle{Shell Integration}
+	Git ships with completion for bash, zsh and tcsh. You may need to source it in the relevant rc
+	file.
 
-	\href{https://github.com/BurntSushi/ripgrep}{https://github.com/BurntSushi/ripgrep}
+	Prompt customisation is available out of the box for bash and zsh.
 	\note{%
-		Alternatives to grep and find
-
-		Fd, in particular, is not a full replacement for find but does most of what you want
-
-		Both (by default) will respect your gitignore file.
+		If you haven't ever tried zsh, give it a shot. Tab completion is so much more useful than
+		Bach's.
 	}
 \end{frame}
 
 \begin{frame}
 	\frametitle{Useful supporting tools}
-	\framesubtitle{Delta}
-	\begin{center}
-		\includegraphics[width=\textwidth,height=0.6\textheight,keepaspectratio]{auto-download-aHR0cHM6Ly91c2VyLWltYWdlcy5naXRodWJ1c2VyY29udGVudC5jb20vNTIyMDUvNjUyNDg1MjUtMzIyNTA0ODAtZGFlYS0xMWU5LTk5NjUtMWEwNWM2YTRiZGY0LnBuZw==.png}
-	\end{center}
-	\href{https://github.com/dandavison/delta}{https://github.com/dandavison/delta} 
+	\framesubtitle{Editor Plugin}
+	\begin{itemize}
+		\item Git Gutters
+		\item Easy staging of parts of a file
+		\item Merge Conflict Resolution
+	\end{itemize}
 	\note{%
-		This is a tool that can make your diff output look better.
+		There are obviously hundreds of editors so find one that works well with yours.
+
+		I think Atom and VS Code have built in integration. 
+
+		I use vim-fugitive. I've heard good things about magit for emacs.
 	}
 \end{frame}
 
@@ -1095,14 +1131,66 @@ can really help.
 
 \begin{frame}
 	\frametitle{Useful supporting tools}
-	\framesubtitle{Shell Integration}
-	Git ships with completion for bash, zsh and tcsh. You may need to source it in the relevant rc
-	file.
+	\framesubtitle{Git Crypt}
 
-	Prompt customisation is available out of the box for bash and zsh.
+	For storing sensitive information in a git repository.
+
+	\href{https://github.com/AGWA/git-crypt}{https://github.com/AGWA/git-crypt}
 	\note{%
-		If you haven't ever tried zsh, give it a shot. Tab completion is so much more useful than
-		Bash's.
+		This will encrypt files with gpg key(s) and transparently decrypt them on the file system.
+	}
+\end{frame}
+
+\begin{frame}
+	\frametitle{Useful supporting tools}
+	\framesubtitle{Git Large File Storage}
+
+	A solution to the issue of storing binary files
+
+	\href{https://git-lfs.github.com/}{https://git-lfs.github.com/}
+	\note{%
+		As mentioned, git is not good at storing binary files because they can't be compressed or
+		diff-ed or merged.
+
+		This allows you to store links to large files and transparently add them to the file system
+		as though they were normal git blobs.
+	}
+\end{frame}
+
+\begin{frame}
+	\frametitle{Useful supporting tools}
+	\framesubtitle{Bat}
+	\begin{center}
+		\includegraphics[width=\textwidth,height=0.8\textheight,keepaspectratio]{auto-download-aHR0cHM6Ly9jYW1vLmdpdGh1YnVzZXJjb250ZW50LmNvbS82N2U0NGY0YTY4MTUwMzI1Zjc0YjNhNDY4MjBiNzQ3M2ZmN2I5MWE2LzY4NzQ3NDcwNzMzYTJmMmY2OTJlNjk2ZDY3NzU3MjJlNjM2ZjZkMmYzMjZjNTM1NzM0NTI0NTJlNzA2ZTY3.png}
+	\end{center}
+	\href{https://github.com/sharkdp/bat}{https://github.com/sharkdp/bat}
+	\note{%
+		Bat is described as cat with wings.
+
+		It adds syntax highlighting to files. Useful even if you're not using Git
+
+		As this is a git talk, it shows lines that have changed since the last commit
+	}
+\end{frame}
+
+\begin{frame}
+	\frametitle{Useful supporting tools}
+	\framesubtitle{RipGrep / Fd / Exa}
+
+	\textbf{FD} replaces find
+
+	\href{https://github.com/sharkdp/fd}{https://github.com/sharkdp/fd}
+
+	\textbf{RigGrep} replaces grep
+
+	\href{https://github.com/BurntSushi/ripgrep}{https://github.com/BurntSushi/ripgrep}
+
+	\textbf{Exa} replaces ls
+
+	\href{https://github.com/ogham/exa}{https://github.com/ogham/exa}
+	\note{%
+
+		Fd and RipGrep will respect your gitignore by default.
 	}
 \end{frame}
 
@@ -1147,4 +1235,16 @@ can really help.
 	}
 \end{frame}
 
+\begin{frame}
+	\frametitle{Questions}
+
+	You can find this presentation here:
+
+	\href{https://git.jonathanh.co.uk/jab2870/Git-Presentation}{https://git.jonathanh.co.uk/jab2870/Git-Presentation}
+
+	\note{%
+		Yes, this presentation uses git for version control
+	}
+\end{frame}
+
 \end{document}

shell/add-remote

@@ -1,5 +1,6 @@
 #!/usr/bin/env bash
 
+cd /tmp/demo
 (
 rm -rf /tmp/demo-remote
 mkdir -p /tmp/demo-remote
@@ -7,7 +8,6 @@ git init --bare /tmp/demo-remote
 git remote remove origin
 ) > /dev/null 2>&1
 
-cd /tmp/demo
 echo '$ git remote add origin /tmp/demo-remote'
 git remote add origin /tmp/demo-remote
 echo '$ git remote'

shell/fetch-merge-pull

@@ -22,5 +22,5 @@ git -c color.ui=always status
 echo '$ git log --oneline --all --graph'
 git -c color.ui=always log --oneline --all --graph --decorate=short
 
-echo '$ git merge'
+echo '$ git merge origin/master'
 git -c color.ui=always merge origin/master

shell/tree-empty-git

@@ -0,0 +1,4 @@
+#!/usr/bin/env bash
+echo '$ tree .git'
+cd /tmp/demo
+tree .git