Permalink
Browse files

More changes from the book proof (physical)

  • Loading branch information...
1 parent 5843b74 commit c0faf01e64b9e34ee63088f8633f6169dc84467c @cbx33 committed Sep 16, 2011
Showing with 54 additions and 63 deletions.
  1. +6 −6 afterhours4.tex
  2. +2 −1 afterhours5.tex
  3. +2 −2 afterhours6.tex
  4. +9 −9 chap3.tex
  5. +4 −6 chap4.tex
  6. +7 −7 chap5.tex
  7. +2 −11 chap6.tex
  8. +10 −8 chap7.tex
  9. +12 −13 chap8.tex
View
12 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.
View
3 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}.
View
4 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.
View
18 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}
View
10 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.
View
14 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}.
View
13 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.
View
18 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}
View
25 chap8.tex
@@ -337,7 +337,6 @@ \subsection{A problem shared is a problem bisected}
\begin{code}
john@satsuki:~/coderepo$ grep "Addition" *
-john@satsuki:~/coderepo$
john@satsuki:~/coderepo$ git checkout v1.0a
Note: checking out 'v1.0a'.
@@ -463,7 +462,7 @@ \subsection{Automating the process}
Git will use these status codes and interpret a code of \texttt{0} as \textbf{good} and a code of \texttt{123} as \textbf{bad}.
Below is a copy of our shell script which we have saved as \texttt{test.sh} and have given relevant permissions to allow it to run etc.
-Notice we have had to exclude our \texttt{test.sh} file from the test, else the string \texttt{Addition} would have been found there.
+Notice we have had to exclude our \texttt{test.sh} file from the test, else the string \texttt{Addition} would have been found there which would have returned true every time.
\begin{code}
john@satsuki:~/coderepo$ cat test.sh
@@ -535,9 +534,7 @@ \subsection{Automating the process}
Simon looked confused.
``I used the bisect tool to find the bug. But you're not gonna like what I found.''
-
\thoughtbreak
-
``Simon how could you have done that?'' John was asking the questions and they were coming thick and fast.
``I mean changing the API key for the web sevice whilst developing was not a great idea to start with, but committing that to the repository was rediculous.''
Simon sat there with his head in his hands.
@@ -838,7 +835,7 @@ \subsection{Splitting the atom}
john@satsuki:~/coderepo$
\end{code}
-So now the directory has been split away from the original source code into a new branch, have a think about what steps you would take to bring this into an entirely new repository.
+So now the directory has been split away from the original source code into a new branch. Have a think about what steps you would take to bring this into an entirely new repository.
\begin{callout}{Note}{More backups}
\index{filtering!backup}Git likes to make things easy for you.
@@ -860,7 +857,7 @@ \subsection{Splitting the atom}
We actually have at least four methods we can use to do this.
\begin{enumerate}
-\item Copy the data from one repo to another with copy and paste
+\item Copy the data from one repo to another with a simple copy and paste
\item Clone our repository, delete all of the branches other than \textbf{tester\_split} and then rename it to \textbf{master}
\item Initialise a new repository, setup a remote to the original and then fetch our \textbf{tester\_split} branch
\item Create a bundle of the \textbf{tester\_split} and then clone from the bundle into a new repository
@@ -874,7 +871,7 @@ \subsection{Splitting the atom}
This would happen natually over time as the objects aged and were no longer referenced, but it would result in a repository that was initially much larger than it needed to be.
The other two methods deserve a little more consideration as they both perform much better in this respect.
-The third method you should be familiar enough with pervious material to be able to perform right now.
+The third method you should be familiar enough with previous material to be able to perform right now.
However, using the fetch command as we have done so before would again pull in many more objects than we require.
As such we are going to do a subtle twist to this command in the following output.
@@ -950,7 +947,7 @@ \subsection{Little bundles of joy}
Here we are going to look at just one more way that we can create a new repo from our \textbf{tester\_split} branch.
The tool we are going to introduce here is \indexgit{bundle}.
-\index{bundling!creating}\index{bundling!cloning from}The \texttt{bundle} utility allows us to export a set of revisions and almost archive them to a file.
+\index{bundling!creating}\index{bundling!cloning from}The \texttt{bundle} utility allows us to export a set of revisions and archive them to a file.
This file then becomes a resource that can be updated and pulled or fetched from.
This is especially useful if you have no physical connection between two computers and wish to sync some of the data from one to the other.
Let us take a quick look at how we could use the bundle tool in this case.
@@ -969,7 +966,9 @@ \subsection{Little bundles of joy}
john@satsuki:~$
\end{code}
-So the problem here is that when we created the bundle, the branch which was checked out at the time was \textbf{master}.
+The syntax is fairly simple. The word \texttt{create} is used to tell Git to create a new bundle.
+After this we specify a filename and then the tip of the branch that we want to archive. However, as can be seen above, there is a problem.
+When we created the bundle, the branch which was checked out at the time was \textbf{master}.
The objects we pulled from the source repository and placed in the bundle were all from the \textbf{tester\_split} branch.
As such the HEAD of the working tree at the time of the bundle creation, pointed to an object in the \textbf{master} branch.
Obviously this object does not exist in our bundle and so Git complains.
@@ -979,7 +978,7 @@ \subsection{Little bundles of joy}
As you can see below, it seems as if there are no branches at all and when we try to checkout master it does not exist.
What actually happened is that the objects were cloned into the repository, but as the object that the source HEAD pointed to was unavailable,
no branch was created.
-With a litle \texttt{git reset} trickery, we can create our \textbf{master} branch in our new repository.
+With a little \texttt{git reset} trickery, we can create our \textbf{master} branch in our new repository.
\begin{code}
john@satsuki:~$ cd subrepo-b/
@@ -995,7 +994,7 @@ \subsection{Little bundles of joy}
john@satsuki:~/subrepo-b$
\end{code}
-Now we have our repository complete as before.
+Now we have our repository complete as before and we have successfully reampped the \textbf{master} branch so that it points to \textbf{origin/tester\_split}.
\begin{trenches}
Martha and John were sitting together in the office.
@@ -1042,7 +1041,7 @@ \subsection{Nuclear fusion}
We need to define what a submodule actualy is.
Submodules are tricky to understand and often people use them once and conclude that they are more trouble than they are worth.
However, if you take some time to understand what a submodule really is, then they can be very useful to you.
-A submodule is the inclusion of a repositories branch at a specific commit.
+A submodule is the inclusion of a repository branch at a specific commit.
It is not intended to track the development of the upstream library or module, (see the callout box for an explanation of \emph{upstream}).
\begin{callout}{Terminology}{Upstream}
@@ -1135,7 +1134,7 @@ \subsection{Nuclear fusion}
\subsection{Changes down the river}
So what happens when we want to pull in changes from the upstream project?
-Well, you can make your submodule point to whatever point you like and stay there.
+Well, you can make your submodule point to whatever commit you like and stay there.
As long as you commit your changes in the super project, Git will always allow you to return to that point using the \texttt{git submodule update} command.
Let us take a look at how we could pull in some changes into our \texttt{tester} submodule.

0 comments on commit c0faf01

Please sign in to comment.