More changes from the book proof (physical)

afterhours4.tex

@@ -9,16 +9,16 @@ \subsection{How does merging work?}
 \index{merging!types}\index{merging!types!resolve}\index{merging!types!recursive}\index{merging!types!octopus}\index{merging!types!ours}\index{merging!types!subtree}
 
 \begin{itemize}
-\item\textbf{resolve} - A two headed merge strategy using a 3-way merge algorithm.
+\item\textbf{Resolve} - A two headed merge strategy using a 3-way merge algorithm.
 This is used by default in Git.
-\item\textbf{recursive} - A two headed merge strategy using a 3-way merge algorithm.
+\item\textbf{Recursive} - A two headed merge strategy using a 3-way merge algorithm.
 This algorithm looks at situations where multiple common ancestors are eligible and creates a merged tree of the common ancestors to be used as a reference.
 Usually, this method has less conflicts and carries with it multiple sub-options.
-\item\textbf{octopus} - This merge strategy can merge in multiple heads.
+\item\textbf{Octopus} - This merge strategy can merge in multiple heads.
 When trying to pull multiple topic branches into a single merge, an \textbf{octopus} is the default method that Git will use.
-\item\textbf{ours} - Another multiple head strategy, which simply ignores all changes from the other branches.
+\item\textbf{Ours} - Another multiple head strategy, which simply ignores all changes from the other branches.
 At first it may sound like a useless idea, but it could be used to keep the history of a branch without actually keeping the branch itself.
-\item\textbf{subtree} - A much more advanced merge strategy based on the \textbf{recursive} which trees are adjusted to result in a better merge.
+\item\textbf{Subtree} - A much more advanced merge strategy based on the \textbf{recursive} which trees are adjusted to result in a better merge.
 \end{itemize}
 
 Now that we are aware of the different options available to us, let us discuss what happens when we actually perform a merge.
@@ -104,4 +104,4 @@ \subsection{A subtle twist on searching}
 \end{code}
 
 This is just a short introduction to the \texttt{git grep} command.
-If you want to know more, you should spend some time reading the manual.
+If you want to know more you should spend some time reading the manual.

afterhours5.tex

@@ -255,7 +255,6 @@ \subsection{Taking commits that little bit further}
 john@satsuki:~/coderepo$ git add -p
 ...
 ...
-...
 \end{code}
 
 We have gone through the process of editing each hunk for each commit and have performed the commits.
@@ -285,6 +284,8 @@ \subsection{Taking commits that little bit further}
 Date:   Wed Apr 13 23:55:32 2011 +0100
 
     Added first line
+...
+...
 \end{code}
 
 \index{hunk editing(gui)}Next we are going to see how to perform exactly the same procedure using \texttt{git gui}.

afterhours6.tex

@@ -3,7 +3,7 @@
 \chapter{After Hours Week 6}
 \section{``Tug of war''}
 \subsection{Taking the push with the pull}
-We have spoken in fairly great length about how remote repositories work.
+We have spoken at fairly great length about how remote repositories work.
 We have seen how the \texttt{git remote} tool is used to create the various references to remote repositories, but we have no real understanding about what this means in terms of Git's internals.
 Just in the same way a branch is a single file that contains a pointer to a reference, a remote repository has to be handled within Git somehow.
 
@@ -14,7 +14,7 @@ \subsection{Taking the push with the pull}
 If you have, do not worry, just follow the operations we completed in Week 6, or read on and use the text in the book.
 
 If you remember, we created two clones of our original repository.
-Once was a simple clone called \texttt{coderepo-cl} and the other was a bare repository called \texttt{coderepo-bk}.
+One of these was a simple clone called \texttt{coderepo-cl} and the other was a bare repository called \texttt{coderepo-bk}.
 The \texttt{coderepo-cl} and the \texttt{coderepo-bk} repositories were both cloned from \texttt{coderepo}, but it was \texttt{coderepo-cl} that was configured to pull from one and push to the other.
 Running a simple \texttt{git remote -v} command, confirms this configuration.
 

chap3.tex

@@ -561,15 +561,15 @@ \subsection{Revert, I say. Revert!}
 \begin{center}
   \begin{tabular}{ | l | l | l | l | l | l |}
     \hline
-    Method Name & 
-    \rotatebox{90}{Alters Repository} & 
-    \rotatebox{90}{Changes History} & 
-    \rotatebox{90}{Alters Working Copy} & 
-    \rotatebox{90}{Reversible} & 
-    \rotatebox{90}{Multiple Files}\\ \hline
-    Reset & Possibly & Possibly & Possibly & Possibly & Yes\\ \hline
-    Checkout & No & No & Yes & No & Yes\\ \hline
-    Show & No & No & No & N/A & No\\ \hline
+    \textbf{Method Name} & 
+    \rotatebox{90}{\textbf{Alters Repository}} & 
+    \rotatebox{90}{\textbf{Changes History}} & 
+    \rotatebox{90}{\textbf{Alters Working Copy}} & 
+    \rotatebox{90}{\textbf{Reversible}} & 
+    \rotatebox{90}{\textbf{Multiple Files}}\\ \hline
+    \textbf{Reset} & Possibly & Possibly & Possibly & Possibly & Yes\\ \hline
+    \textbf{Checkout} & No & No & Yes & No & Yes\\ \hline
+    \textbf{Show} & No & No & No & N/A & No\\ \hline
   \end{tabular}
 \end{center}
 \end{table}

chap4.tex

@@ -180,7 +180,7 @@ \subsection{Planting trees}
 Comparing that to our previous \texttt{ls} command, we can see that this is exactly what the working tree looked like at the beginning of the chapter.
 Let us take a look at a diagram of the commit history to see what has happened in our repository.
 
-\figuregith{9cm}{images/f-w4-d1.pdf}{Our first branch}
+\figuregith{7cm}{images/f-w4-d1.pdf}{Our first branch}
 
 \index{pointers}So there are really two pointers in our repository at the moment, from a branch point of view.
 One of them points to commit \textbf{a022d4d\ldots} and is called \textbf{master}.
@@ -202,7 +202,6 @@ \subsection{Planting trees}
 commit 55fb69f4ad26fdb6b90ac6f43431be40779962dd
 ...
 ...
-...
 \end{code}
 
 So here we have added a tag in our current branch, \textbf{wacky}, and we can see that the commit ID for the tag \textbf{v2.0} points \textbf{55fb69f}.
@@ -220,7 +219,6 @@ \subsection{Planting trees}
 commit 55fb69f4ad26fdb6b90ac6f43431be40779962dd
 ...
 ...
-...
 john@satsuki:~/coderepo$ git branch -v
   master a022d4d Messed with a few files
 * wacky  9710177 Added another file
@@ -317,7 +315,7 @@ \subsection{Working with branches}
 Now let us take a quick look at a diagram to see how this change actually affected the commit flow.
 We have included tags in this diagram, so that you can see where they point to as well.
 
-\figuregith{9cm}{images/f-w4-d2.pdf}{Our first merge}
+\figuregith{7cm}{images/f-w4-d2.pdf}{Our first merge}
 
 \index{tagging!difference to branch}\index{branching!difference to tags}This picture should make it clear that the fundamental difference between tags and branches is that whilst the pointer to a branch moves with each commit to that branch, a tag points to a single commit only and never changes, unless forcibly so by the user.
 
@@ -516,7 +514,7 @@ \subsection{More neat ways to work with branches}
 john@satsuki:~/coderepo$
 \end{code}
 
-Now we reach step 4 in our set of instructions.
+Now we reach step four in our set of instructions.
 The one function we do not know how to perform yet is the resetting of our branch back to a previous point in time.
 The point we need to rewind back to is the point that we initially created the \textbf{zaney} branch at.
 We could have gotten this information by using \texttt{git log}.
@@ -702,7 +700,7 @@ \subsection{What to do when it all goes wrong}
 If we wanted to, we could continue on making changes to the \textbf{wonderful} branch and we could keep pulling changes in from one to the other as time went by.
 Figure 5 shows what our repository looks like now.
 
-\figuregith{9cm}{images/f-w4-d5.pdf}{Repository state after \textbf{wonderful} merge}
+\figuregith{11cm}{images/f-w4-d5.pdf}{Repository state after \textbf{wonderful} merge}
 
 Our repository tree looks a little strange now.
 Notice that the most recent commit, \textbf{b119573}, has two parents.

chap5.tex

@@ -104,7 +104,7 @@ \subsection{A little bit of graphics}
 \index{GUI!unstaged}If we take a closer look at the \textbf{Unstaged} area of the screen, we see something interesting.
 This is shown in Figure 2.
 
-\figuregith{5cm}{images/f-w5-d2.png}{Unstaged section}
+\figuregith{5cm}{images/f-w5-d2.png}{Unstaged section showing our \texttt{temp\_file}}
 
 This is the only file in our working copy which contains unstaged changes.
 That should not be surprising as this file has never been added to the repository so it is not considered \textbf{tracked} by Git.
@@ -122,7 +122,7 @@ \subsection{A little bit of graphics}
 \index{GUI!staged}Now the file has moved into the \textbf{Staged} area of the screen as would be equivalent to us doing a \texttt{git add temp\_file}.
 The file has been added to the index and is now ready for committing.
 We also notice a difference in the \textbf{Content View} of \texttt{temp\_file}.
-This can be seen in Figure 5.
+This can be seen in Figure 5 and now shows a patch view of addition of the file, as opposed to just the contents of the file.
 
 \figuregith{11cm}{images/f-w5-d5.png}{Content view of \texttt{temp\_file}}
 
@@ -135,7 +135,7 @@ \subsection{A little bit of graphics}
 We will finish this section off by checking the status area at the very bottom of the screen.
 In Figure 7, you should see that our latest operation has been summarised by the string \texttt{Created commit 35243bf8: Added temp\_file}
 
-\figuregith{11cm}{images/f-w5-d7.png}{Status message showing new commit ID}
+\figuregith{11cm}{images/f-w5-d7.png}{Status message showing a new commit ID}
 
 \section{Day 2 - ``Back to logging''}
 \subsection{Visualisation to the max}
@@ -144,7 +144,7 @@ \subsection{Visualisation to the max}
 
 Whichever way we begin an instance of \texttt{gitk}, we are likely to end up with a screen like the one in Figure 8.
 
-\figuregith{11cm}{images/f-w5-d8.png}{Initial \texttt{gitk} view}
+\figuregith{11cm}{images/f-w5-d8.png}{Initial \texttt{gitk} view of our repository}
 
 Let us spend a few minutes familiarising ourselves with the layout of the \texttt{gitk} tool.
 The window is split up into roughly seven different areas.
@@ -166,7 +166,7 @@ \subsection{Visualisation to the max}
 Essentially this is just a very simplified version of the graphs we were drawing in the previous chapter.
 As you can see, the only information that appears to be missing from the graph is the commit ID, which can be obtained quite easily by clicking on the relevant commit and viewing the string presented just below the graph pane.
 
-\figuregith{10cm}{images/f-w5-d9.png}{Graphical history of repository}
+\figuregith{10cm}{images/f-w5-d9.png}{Graphical history of our repository}
 
 The historical graph shows us all active branches, tags and commits.
 From looking at this it is easy to see where our merges occurred and where the branch HEADs point to.
@@ -175,7 +175,7 @@ \subsection{Visualisation to the max}
 
 \index{GUI!content view (gitk)}If we select the \textbf{master} branch HEAD, which should be the top commit, (in fact on opening \texttt{gitk} this should already be selected), we should see a pane similar to Figure 10 in the \textbf{Content View} section of the screen.
 
-\figuregith{10cm}{images/f-w5-d10.png}{Content view of master HEAD}
+\figuregith{10cm}{images/f-w5-d10.png}{Content view of \textbf{master} HEAD}
 
 Notice in this that we have two parents listed, which is what we would expect, as the last commit we did was that of a merge from \textbf{zaney} into \textbf{master}.
 Notice also that below this, we get to see a diff output of exactly what changed during this merge.
@@ -206,7 +206,7 @@ \subsection{Visualisation to the max}
 After you have finished typing you should already have noticed a difference in the \textbf{History Graph} pane.
 Notice how some commits are now highlighted in bold, as demonstrated in Figure 12?
 
-\figuregith{10cm}{images/f-w5-d12.png}{Search results}
+\figuregith{10cm}{images/f-w5-d12.png}{Search results are highlighted}
 
 If you remember from Week 3, when we first ran the \texttt{git log -S "Change1"} command, we were presented with only one commit.
 That was titled, \texttt{Made a few changes to first and second files}.

chap6.tex

@@ -215,17 +215,9 @@ \subsection{Attack of the clones}
 \begin{code}
 john@satsuki:~$ git clone coderepo coderepo-cl
 Initialized empty Git repository in /home/john/coderepo-cl/.git/
-john@satsuki:~$
-\end{code}
-
-\begin{code}
 john@satsuki:~$ cd coderepo-cl
 john@satsuki:~/coderepo-cl$ ls
 another_file  newfile1  newfile2
-john@satsuki:~/coderepo-cl$
-\end{code}
-
-\begin{code}
 john@satsuki:~/coderepo-cl$ git status
 # On branch master
 nothing to commit (working directory clean)
@@ -488,8 +480,6 @@ \subsection{Pulling changes, not teeth}
 
 \begin{code}
 john@satsuki:~/coderepo$ cd ../coderepo-cl/
-john@satsuki:~/coderepo-cl$ git diff wonderful origin/
-origin/HEAD        origin/master      origin/wonderful   origin/zaney
 john@satsuki:~/coderepo-cl$ git diff wonderful origin/wonderful
 john@satsuki:~/coderepo-cl$
 \end{code}
@@ -547,7 +537,8 @@ \subsection{Pulling changes, not teeth}
 \end{code}
 
 As you can see, the two commands that we used were \indexgit{fetch} and the more familiar \texttt{git merge}.
-The \texttt{git fetch} command literally visits the remote repository, in our case we asked for \textbf{origin}, and finds which objects are new.
+The \texttt{git fetch} command literally visits the remote repository, in our case we asked for \textbf{origin}, and finds which objects are new 
+and do not exist in our local clone.
 These are then copied to the local clone, and the HEADs of the various remote branches are updated.
 We now rerun our \texttt{git diff}, only this time, we see a great many more changes than before.
 Finally we initiate a \texttt{git merge} to pull the changes from the now up to date remote branch to our local one.

chap7.tex

@@ -145,8 +145,8 @@ \subsection{Pure collaboration}
 This branch is not guaranteed to be stable.
 Sometimes things will break but the development branch is a place that all of the work of the various teams comes together.
 
-Once the teams hit feature freeze, the point at which they will no longer take any more new features into the code base, they will ask the QA manager to create a \textbf{QA} branch.
-Bug fixes for current issues will be committed here and when all bugs have been fixed and the code is ready to be released, the release branch will be synced with a specific commit of the \textbf{QA} branch.
+Once the teams hit feature freeze, the point at which they will no longer take any more new features into the code base, they will ask the QA manager to create a \textbf{qa} branch.
+Bug fixes for current issues will be committed here and when all bugs have been fixed and the code is ready to be released, the release branch will be synced with a specific commit of the \textbf{qa} branch.
 
 If this all sounds a little confusing, we will take a few minutes to digest what we have come up with and draw a few diagrams.
 The beauty of Git is that it is so configurable and so by design supports almost limitless workflows.
@@ -160,7 +160,7 @@ \subsection{Pure collaboration}
 This is the repository that contains our main \textbf{release} branch.
 This branch will always contain reliable stable releases.
 Sure, it may contain history of how we reached the stable release, but on a checkout, it will be a solid, buildable, pristine, tagged release.
-This repository also contains our \textbf{QA} branch.
+This repository also contains our \textbf{qa} branch.
 This is the branch that upon checkout would contain a fairly polished version of the product, but it may still have a few bugs and issues.
 Then we have our development branch.
 This is where the integration managers from the various teams would pull the code from their teams into a single code base, ready for the QA manager to begin his testing.
@@ -734,13 +734,13 @@ \subsection{Migrating commits}
 
 \index{cherry picking}Cherry picking is a method of copying the contents of one commit into another and is something that we will pick up on later, but we will first look at our final use of rebase.
 Imagine the scenario painted above.
-You made a branch, have been merrily committing for hours, before realising that actually you branched from the wrong place.
+You made a branch, have been merrily committing for hours, before realising that actually you branched from the wrong ancestor.
 
 In Git, this isn't a problem.
-Things get complicated if you've been doing more advanced operations during this period, but if you have been simply adding commits, we can use rebase to migrate that tree of commits to a different ancestor.
+Things get complicated if you've been doing more advanced operations during this period, but if you have been simply adding commits, we can use rebase to migrate the tree of commits to a different ancestor.
 
-Take the example we have been working on, currently we have a \textbf{master} branch and a \textbf{wonderful} branch, and these differ.
-Let us say we are currently sitting on the \textbf{wonderful} branch, but we thought we were on the \textbf{branch} and we created a new branch called develop.
+Take the example we have been working on. Currently we have a \textbf{master} branch and a \textbf{wonderful} branch, and these differ, though they have a common ancestor.
+Let us say we are currently sitting on the \textbf{wonderful} branch, but we thought we were on \textbf{master} and we created a new branch called \textbf{develop}.
 
 \begin{code}
 john@satsuki:~/coderepo$ git checkout -b develop
@@ -779,6 +779,7 @@ \subsection{Migrating commits}
 \end{code}
 
 Whoops! The commits were supposed to be on a branch that stemmed from \textbf{master}, not one that stems from \textbf{wonderful}.
+In other words, \textbf{develop} stems from \textbf{wonderful}, when it should have stemmed from \textbf{master}.
 This is where \texttt{git rebase} comes to our assistance once more.
 With one command, we can move those commits to a branch that stems from \textbf{master}.
 
@@ -802,8 +803,9 @@ \subsection{Migrating commits}
 \end{code}
 
 Notice in the output above that we have used our \texttt{git rebase} tool with a new \texttt{--onto master} parameter.
-Basically the syntax is stating that we would like to take the commits between \textbf{wonderful} and \textbf{develop} and place them onto \textbf{master} instead.
+Basically the syntax above is stating that we would like to take all of the commits between the points \textbf{wonderful} and \textbf{develop} and place them onto \textbf{master} instead.
 
+\subsection{A little housework}
 To clean up our repository, we are going to delete our \textbf{keeprebase} branch.
 
 \begin{code}