Miscellaneous updates

git-primer.tex

@@ -181,7 +181,7 @@ If this is your first exposure to version control software you'll make faster pr
 
 \paragraph{Concept Two: The basic time unit of Git is a \textit{commit}.} A commit is simply a snapshot of where your project stands at any given moment. When you make a commit, it's like taking a picture of your project at that particular moment.
 
-\paragraph{Concept Three: The basic space unit of Git is a \textit{repository}.} All those commmits have to live somewhere, and a repository is just a place where all those commits exist. Repositories (or ``repos'' for short) can be \textit{local}—that is, they exist on your computer only—or they can be \textit{remote}—meaning that can live on other computers somewhere else. That ``somewhere else'' is usually a publicly available server. You can create your own or you can get an account at someplace like Gitlab or GitHub, which are privately run for-profit companies, or at someplace like Codeberg, which is run by a non-profit entity. 
+\paragraph{Concept Three: The basic space unit of Git is a \textit{repository}.} All those commmits have to live somewhere, and a repository is just a place where all those commits exist. Repositories (or ``repos'' for short) can be \textit{local}—that is, they exist on your computer only—or they can be \textit{remote}—meaning that can live on other computers somewhere else. That ``somewhere else'' is usually a publicly available server. You can create your own or you can get an account at some place like Gitlab or GitHub, which are privately run for-profit companies, or at someplace like Codeberg,\footnote{\kref{https://codeberg.org/}{https://codeberg.org/}} which is run by a non-profit entity. 
 
 You can work with a local repository only, or you can decide to work with one or more remote repositories. The choice is up to you. 
 
@@ -189,15 +189,21 @@ You can work with a local repository only, or you can decide to work with one or
 
 \section{Git Clients}
 
-Git is a command line based technology. Yes, there are GUIs out there for Git, and if you are on Windows or macOS, you may find them useful. You can see a fairly comprehensive list at \kref{https://git-scm.com/book/en/v2/Getting-Started-Installing-Git}{https://git-scm.com/book/en/v2/G\\etting-Started-Installing-Git}.
+Git is a command line based technology. Yes, there are GUIs (Graphical User Interfaces) out there for Git, and if you are on Windows or macOS, you may find them useful. You can see a fairly comprehensive list at \kref{https://git-scm.com/book/en/v2/Appendix-A:-Git-in-Other-Environments-Graphical-Interfaces}{https://git-scm.com/book/en\\/v2/Appendix-A:-Git-in-Other-Environments-Graphical-Interfaces}.
 
-In general, I advise against using any type of GUI with Git. For one thing, Git is fairly easy to manage from the command line, so using a GUI just adds a level of abstraction that we don't really need. For another, the command line is forever, but GUIs come and go. If your GUI gets to a point where it's development is discontinued, or it decides to adopt a subscription model that you can't afford, you're screwed.
+In general, I advise against using any type of GUI with Git. For one thing, Git is fairly easy to manage from the command line, so using a GUI just adds a level of abstraction that we don't really need. For another, the command line is forever, but GUIs come and go. If your GUI gets to a point where it's development is discontinued, or it decides to adopt a subscription model that you can't afford, you're in trouble.
 
 A GUI can also obscure what Git is actually doing, meaning that you might end up with less understanding of Git than you would by working on the command line.
 
+\section{Assumptions}
+
+That said, this document assumes that you are familiar with working on the command line in whatever OS you are accustomed to. You do not have to be an expert with it (that comes with time) but you should know how to open a terminal window, enter commands, and interpret whatever feedback you get. 
+
 \chapter{Local Repositories}
 
-Let's start with local repositories. Assuming you have a folder full of files you want to track using Git, open a terminal window in that location (which is now called your ``working directory'') and type \texttt{git init}. Congratulations! You now have a local Git repo!
+Repositories are the basic space unit of Git. You can have as many of them as you want, both locally and remotely. Most people only have a single local repository, so let's start there.
+
+Assuming you have a folder full of files you want to track using Git, open a terminal window in that location (which is now called your ``working directory'') and type \texttt{git init}. Congratulations! You now have a local Git repo!
 
 What has happened is that Git has created an invisible directory (\texttt{.git}) that it will use to store the metadata and database for your project. Do \textbf{not} delete this folder! 
 
@@ -205,9 +211,11 @@ Technically, the \texttt{.git} directory is the actual repository. But most peop
 
 We haven't made any commits yet, though. All we have are files in our working directory. To make a commit, we need to \textit{stage} our files by using the \texttt{git add} command. You can do this a couple of different ways: we can either list each file one by one (i.e., \texttt{git add file1.txt file2.txt}) or we can just add them all in a single go by using the \texttt{*} wildcard (\texttt{git add *} which will \textit{not} add invisible files, or \texttt{git add -A} which \textit{will} add invisible files).
 
+Before you stage files, though, it's a good idea to examine the status of your project. The command for that is \texttt{git status}.
+
 Now that you've added your files, they are considered to be \textit{staged}, which means that they are ready to commit. You can make a commit now, or you can modify or create new files, and then add them as well. The choice is yours—Git doesn't penalize you either way. Personally, I prefer to make many smaller commits to avoid losing data (and metadata).
 
-If you're happy with the files you've staged, we can now commit them by using \texttt{git commit -m "<commit message>"}. Note that you have to add a commit message. This can be anything you like, but it helps to make it something that will be useful down the road like ``updated chapter three''. You'll get some miscellaneous messages about what Git is doing and then it is done. You've created your first commit, and all of your staged files are now \texttt{committed}.\footnote{You can also make this process even more efficient by creating some bash alias for the various Git commands. See ``More Fun with bash'' in issue \#4.}
+If you're happy with the files you've staged, we can now commit them by using \texttt{git commit -m "<commit message>"}. Note that you have to add a commit message. This can be anything you like, but it helps to make it something that will be useful down the road like ``updated chapter three''. You'll get some miscellaneous messages about what Git is doing and then it is done. You've created your first commit, and all of your staged files are now \texttt{committed}.
 
 \chapter{Branches}
 
@@ -253,7 +261,7 @@ If you set up a remote repo on some place like GitHub, or you find a repo somewh
 
 \input{include/clone}
 
-For example, if you wanted to get a copy of the Apollo 11 Guidance Computer source code because you happen to be planning a trip to the moon of your own,\footnote{I was delighted to find out that this was available on GitHub. I first learned about this in the Volume Thirty-Eight, Number Four issue of \textit{2600} in an article called ``Supply and Demand, Apollo 11, and GitHub'', which is something I will probably talk about in the future.} you would just type \texttt{git clone https://github.com/chrisl\\garry/Apollo-11}. Git would create a directory called ``Apollo-11'' and clone a local version of that entire repository into it.
+For example, if you wanted to get a copy of the Apollo 11 Guidance Computer source code because you happen to be planning a trip to the moon of your own,\footnote{I was delighted to find out that this was available on GitHub. I first learned about this in the Volume Thirty-Eight, Number Four issue of \textit{2600} in an article called ``Supply and Demand, Apollo 11, and GitHub''.} you would just type \texttt{git clone https://github.com/chrisl\\garry/Apollo-11}. Git would create a directory called ``Apollo-11'' and clone a local version of that entire repository into it.
 
 If you want to see the remotes attached to this repo, you can just type \texttt{git remote -v}. In this case, it would show you something like this:
 
@@ -399,11 +407,13 @@ Command & Purpose {\& Example, if applicable} \\
 \texttt{git branch -{}-show-current}			& Show only the current branch \\
 \texttt{git commit}	& {Commits stages files \\ \texttt{git commit -m} ``<commit message>'' } \\
 \texttt{git fetch} & Get the change history of a specific tracked remote and branch \\
+\texttt{git log} & \\
 \texttt{git merge} & Incorporate changes from the named commits into the current branch \\
 \texttt{git pull} & A combination of \texttt{fetch} and \texttt{merge} \\
 \texttt{git push}	& {Pushes a commit from a local repo to a remote repo \\ \texttt{git push} <name of remote repo> <name of remote branch> } \\
 \texttt{git remote}		& {Show only the names of remote repos  \\ \texttt{git remote} } \\
 \texttt{git remote -v}	& {Show both the names and URLs of remote repos  \\ \texttt{git remote -v} } \\
+\texttt{git rev-list} & \\
 \texttt{git status}	& Show which files have been staged and which files are waiting to be staged \\
 \texttt{git status -s}	& As above, but in short form \\
 \texttt{git status -u}	& As above, but only show untracked files \\