Added atypical output from git status

git-primer.tex

@@ -33,6 +33,7 @@
 \usepackage{setspace}
 \usepackage[obeyDraft, textcolor=red2, bordercolor=red, backgroundcolor=white, textsize=small]{todonotes}
 
+
 %\usepackage{showframe}
 %\renewcommand*\ShowFrameColor{\color{red}}
 
@@ -195,6 +196,11 @@ The \texttt{tabularray} package is, hands-down, the best package for creating ta
 
 \thispagestyle{empty} % hide page numbers on TOC
 
+\newpage
+\phantom{This is here just to make a blank page on the back of the TOC.}
+\thispagestyle{empty} % hide page numbers on the back of the TOC
+
+
 \pagenumbering{arabic} % turn page numbers back on
 
 \chapter{Introduction}
@@ -230,7 +236,7 @@ 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 (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}.
+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:-G\\it-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 in trouble.
 
@@ -314,53 +320,12 @@ You can list individual files, or you can use wildcards to match multiple files.
 \item Any line starting with a \texttt{\#} is a comment, so you can remind yourself of why you are ignoring something.
 \end{itemize}
 
-\section{Committing Stages Files}
+\section{Committing Staged Files}
 
 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 committed.
 
-\chapter{Branches}
-
-If you want to experiment, the best way to do that is to create a \textit{branch}. There are two steps to this:
-
-\begin{enumerate}
-\item Create a branch using \texttt{git branch <name>}.
-\item Move to that branch using \texttt{git branch checkout <branchname>}.
-\end{enumerate}
-
-Of course, there's a shortcut to this. You can use 
-
-\input{include/checkout}
-
-\noindent{}which creates a branch called ``branchname'' and moves you to it automatically. 
-
-This is the point where you can experiment and have fun on this branch without worrying about messing up your main branch. If you like the changes that you made on this branch, you can then go back to your main branch (\texttt{git checkout main}) and \textit{merge} those changes. 
-
-\input{include/merge}
-
-It's always a good idea to clean up after ourselves. If we don't need that experimental branch any more, we can delete it with \texttt{git branch -d <branchname>}.
-
-In reality, things are rarely going to be this simple, unless you are only making very basic changes to a branch. You'll possibly get all sorts of error messages or warning messages, and will get confused or even scared. The nice thing about Git is that most of the solutions you need are easily found at the other end of a web search by looking up the error message you received.
-
-\section{A Basic Branching Example}
-
-To get a basic understanding of how branching works in Git, let's start with a simple example. We'll assume that we have a single document called \texttt{doc\_a.txt}. It only contains two lines:
-
-\label{doc-aIC}
-\begin{Verbatim}[frame=lines, numbers=left, xleftmargin=5mm, framesep=3mm, breaklines=true, label=\fbox{doc\_a.txt Initial Contents}]
-This is line A1.
-This is line A2.
-\end{Verbatim}
-
-Let's go ahead and commit those using the following set of commands:
-
-\input{include/branch001}
-
-Notice that we don't have a remote repository at this point, so all we are doing is making commits.
-
-\todo[inline]{Talk about git \texttt{diff here}.}
-  
 
 \chapter{Remote Repositories}
 
@@ -450,6 +415,66 @@ As we can see from this example, you can have multiple remotes. I can create a r
 
 \todo[inline]{Add information about changes to remote repos by other people (See "git status" in "local repositories".}
 
+If you are working on a project that others are also working on, running \texttt{git status} may show you something like this:
+
+\begin{Verbatim}[frame=lines, numbers=left, xleftmargin=5mm, framesep=3mm, breaklines=true, label=\fbox{Atypical Output from git status}]
+On branch main
+Your branch is behind 'ogit/main' by 1 commit, and can be fast-forwarded.
+  (use "git pull" to update your local branch)
+ 
+Changes to be committed:
+  (use "git restore --staged <file>..." to unstage)
+	modified:   file1.txt
+
+Untracked files:
+  (use "git add <file>..." to include in what will be committed)
+	file2.txt
+	file3.txt
+\end{Verbatim}
+
+
+
+\chapter{Branches}
+
+If you want to experiment, the best way to do that is to create a \textit{branch}. There are two steps to this:
+
+\begin{enumerate}
+\item Create a branch using \texttt{git branch <name>}.
+\item Move to that branch using \texttt{git branch checkout <branchname>}.
+\end{enumerate}
+
+Of course, there's a shortcut to this. You can use 
+
+\input{include/checkout}
+
+\noindent{}which creates a branch called ``branchname'' and moves you to it automatically. 
+
+This is the point where you can experiment and have fun on this branch without worrying about messing up your main branch. If you like the changes that you made on this branch, you can then go back to your main branch (\texttt{git checkout main}) and \textit{merge} those changes. 
+
+\input{include/merge}
+
+It's always a good idea to clean up after ourselves. If we don't need that experimental branch any more, we can delete it with \texttt{git branch -d <branchname>}.
+
+In reality, things are rarely going to be this simple, unless you are only making very basic changes to a branch. You'll possibly get all sorts of error messages or warning messages, and will get confused or even scared. The nice thing about Git is that most of the solutions you need are easily found at the other end of a web search by looking up the error message you received.
+
+\section{A Basic Branching Example}
+
+To get a basic understanding of how branching works in Git, let's start with a simple example. We'll assume that we have a single document called \texttt{doc\_a.txt}. It only contains two lines:
+
+\label{doc-aIC}
+\begin{Verbatim}[frame=lines, numbers=left, xleftmargin=5mm, framesep=3mm, breaklines=true, label=\fbox{doc\_a.txt Initial Contents}]
+This is line A1.
+This is line A2.
+\end{Verbatim}
+
+Let's go ahead and commit those using the following set of commands:
+
+\input{include/branch001}
+
+Notice that we don't have a remote repository at this point, so all we are doing is making commits.
+
+\todo[inline]{Talk about git \texttt{diff here}.}
+  
 
 \chapter{Collaborating With Yourself — A Guide for Creatives}