Taken extra lines out

Reworded some section titles to make them shorter

chap2.tex

@@ -2,7 +2,6 @@
 \chapter{Week 2}
 \section{Day 1 - ``We are coders, we use Git!''}
 \subsection{Setting Up the Environment}
-
 So now we are ready to begin delving into and actually using Git, right? Well, not exactly.
 First we have to decide upon how the workflow model we have envisaged is implemented in our version control system.
 With Git being so versatile, it's both a blessing and a danger.
@@ -136,7 +135,6 @@ \subsection{Initialising A Repository}
 
 \section{Day 2 - ``Making commitments''}
 \subsection{Let's work on our repository}
-
 The most simple way of committing a file into the repository is to create it, or copy it to the working copy of our repository and use the commands below.
 The working copy is the version of the repository we have currently checked out.
 This terminology will be explained more later on.
@@ -207,7 +205,6 @@ \subsection{Let's work on our repository}
 So this means that Git has recognised and remembered that we are expecting these files to be committed when we next run a \texttt{git commit}.
 
 \subsection{Committing the Uncommitted}
-
 \begin{trenches}
 ``John, what is going on here?'' shouted Klaus from across the hallway.
 The entire office had heard Klaus banging his hands down on the desk for the last fifteen minutes.
@@ -314,9 +311,7 @@ \subsection{Committing the Uncommitted}
 \end{code}
 
 \section{Day 4 - ``Let's do this right, not fast''}
-
 \subsection{Uh-Oh I Think I Made A Mistake}
-
 So now we are fairly well acquainted with adding files into the repository and performing commits.
 In a short while we will learn about how to view the changes we have made and perform diffs against various objects.
 Before we close out the week, we need to go back to the trenches one last time.

chap3.tex

@@ -2,11 +2,9 @@
 \cleardoublepage
 %\phantomsection
 \chapter{Week 3}
-\section{Day 1 - ``But how do I see what's going on?''}
+\section{Day 1 - ``How do I see what's going on?''}
 \subsection{Logging in Git}
-
-\index{logging}
-Perhaps the best feature of a version control system is the level of accountability that it offers if set up correctly.
+\index{logging}Perhaps the best feature of a version control system is the level of accountability that it offers if set up correctly.
 What do we mean by this? People often mistake the word \textbf{accountability} for the word \textbf{blame}.
 This is not true at all.
 Accountability is key in understanding the events that led up to a particular bug being introduced, or a situation occurring.
@@ -119,7 +117,6 @@ \subsection{Logging in Git}
 
 \section{Day 2 - ``But I need more information''}
 \subsection{Digging a little deeper}
-
 \begin{trenches}
 ``I know John, and next time I will make a note of it, but right now, I'd really like to know where this file got changed,'' Klaus pointed at the piece of paper containing a print out, ``specifically when this function was introduced.''
 
@@ -186,7 +183,6 @@ \subsection{Digging a little deeper}
 
 \section{Day 3 - ``What actually changed?''}
 \subsection{Doing the diff dance}
-
 Knowing what the committer thinks they committed is brilliant.
 However, sometimes it's just not enough.
 The reason for this is stated fairly precisely in the first sentence of this paragraph, so let us add a little formatting to bring out the real meaning.
@@ -445,7 +441,6 @@ \subsection{Diffing Over A Range}\index{diff!over a range}
 
 \section{Day 4 - ``Finding a good reference point''}
 \subsection{Tag you're it!}\index{tagging}
-
 During software development, a project will generally get to a point where it is ready to be released to people outside of the development team.
 When this grand day occurs, it is crucial that both the developers and the users have a reference point with which to refer to the state of the code.
 Having a code name or a version number means that within a very short period of time, both parties can converse about a problem, safe in the knowledge that they are on the same page.
@@ -519,9 +514,8 @@ \subsection{Tag you're it!}\index{tagging}
 This will all become clearer during the next week, but fits in with the overall ethos of working with version control systems, if someone has seen the past, you should not EVER change it.
 \end{callout}
 
-\section{Day 5 - ``Putting things back the way they were''}
+\section{Day 5 - ``Putting things back again''}
 \subsection{Revert, I say. Revert!}
-
 Whilst working with your repository, something occurs quite often, is the need to go back in time, either temporarily or permanently, or even partially.
 Git allows you to do this in a multitude of ways.
 Let's see a real life situation where this need could arise.

chap4.tex

@@ -2,9 +2,8 @@
 \cleardoublepage
 %\phantomsection
 \chapter{Week 4}
-\section{Day 1 - ``Finally we're getting somewhere''}
+\section{Day 1 - ``We're getting somewhere''}
 \subsection{Planting trees}
-
 Tamagoyaki Inc have now realised that they have to take these things slow and steady if they want to implement a stable and robust system.
 This week, they are going to start actually using branches and merging in changes, probably one of the largest topics to cover when doing any type of collaborative development.
 
@@ -242,7 +241,6 @@ \subsection{Planting trees}
 
 \section{Day 2 - ``Branches galore''}
 \subsection{Working with branches}
-
 Now we know about branches in general, we should really learn about how to merge changes from one branch into another.
 Branches are fantastic for trying new things out and testing ideas, but if those ideas are successful, we need a way of pulling those changes into our \textbf{master} branch.
 
@@ -436,7 +434,6 @@ \subsection{Working with branches}
 
 \section{Day 3 - ``Tricking the twigs''}
 \subsection{More neat ways to work with branches}
-
 This is only the beginning of the fantastic feature set that Git offers.
 By knowing how Git handles your data, you can make it work for you.
 Let us take a look at another situation you may find yourself in.
@@ -567,7 +564,6 @@ \subsection{More neat ways to work with branches}
 * 163f061 (v0.9) Made a few changes to first and second files
 * cfe23cb My First Ever Commit
 john@satsuki:~/coderepo$
-
 \end{code}
 
 \index{graphing}The \texttt{--graph} parameter, tells Git to draw a graph down the left hand column.
@@ -583,7 +579,6 @@ \subsection{More neat ways to work with branches}
 
 \section{Day 4 - ``I pressed delete...''}
 \subsection{Handling the pressure}
-
 \index{branching!deleting}\index{branching!recovering}We have had some awesome fun working with branches, and hopefully you can see how utterly powerful Git is.
 Sometimes though we can get ourselves into trouble and it is here that Git can also come to our rescue.
 Let us learn how to delete a branch.
@@ -649,7 +644,6 @@ \subsection{Handling the pressure}
 
 \section{Day 5 - ``Conflicting information''}
 \subsection{What to do when it all goes wrong}
-
 \index{conflicts}The team have been playing with branches for a few days now and are beginning to settle into the idea of branching often.
 As you can see, in Git, a branch is a really simple device for allowing experimentation and development.
 As the implementation of branches is so simple, it is also really fast to switch between branches.

chap5.tex

@@ -4,7 +4,6 @@
 \chapter{Week 5}
 \section{Day 1 - ``This isn't working for me John''}
 \subsection{Dealing with resistance}
-
 So, now that the team have discovered the basics of branching, they are conceptually ready to start using it in earnest.
 When implementing a version control system, or shifting from one to another, it is important to make sure that the users are happy with the system and know how to use it.
 Training is a big issue.
@@ -142,7 +141,6 @@ \subsection{A little bit of graphics}
 
 \section{Day 2 - ``Back to logging''}
 \subsection{Visualisation to the max}
-
 \index{gitk@\texttt{gitk}}With the basic operations down, as we discovered in Week 1, let us now move on to using the GUI to view the history of our database.
 The visualiser that is bundled with Git is packed with features and can be invoked in one of two ways, either by running \texttt{gitk} from the command line, or by choosing \textbf{\emph{Repository - Visualize All Branch History}} or \textbf{\emph{Repository - Visualize master's Branch History}}, the latter menu item is worded with the assumption that you are on the \textbf{master} branch of course.
 

chap6.tex

@@ -4,7 +4,6 @@
 \chapter{Week 6}
 \section{Day 1 - ``My private little stash''}
 \subsection{Getting interrupted}
-
 \index{stashing}We're getting close to the point where we can really start using Git as we originally intended, the team at Tamagoyaki Inc.
 are also getting much more acquainted with the operations of both version control and Git in particular.
 Unfortunately things don't always go as smoothly as we would like.
@@ -163,7 +162,6 @@ \subsection{Getting interrupted}
 
 \section{Day 2 - ``What?! No backup?''}
 \subsection{Attack of the clones}
-
 We now know about basic branching and merging.
 At this stage, there is on important topic we must cover briefly, and this is subject of cloning.
 Cloning allows you to make a complete copy of your repository, including all of its history and all of the branches.
@@ -244,7 +242,6 @@ \subsection{Attack of the clones}
 
 \section{Day 3 - ``Is this clone for real?''}
 \subsection{Not entirely as expected}
-
 We now have a clone of the repository and we can start to look at how we can play with branches and see how the two are different.
 
 \begin{trenches}
@@ -431,7 +428,6 @@ \subsection{Not entirely as expected}
 
 \section{Day 4 - ``Help I'm no longer up to date?''}
 \subsection{Pulling changes, not teeth}
-
 With a remote tracking branch, we can pull in the changes from the remote repository.
 In our case, the remote repository is in the \texttt{coderepo} directory that we created at the start of the book.
 In the \texttt{coderepo-cl} directory we have a separate, self-contained copy of the repository.
@@ -562,7 +558,6 @@ \subsection{Pulling changes, not teeth}
 
 \section{Day 5 - ``I'm putting my foot down''}
 \subsection{Pushing back!}
-
 We now know a lot about remote locations right? We are ready to start collaborating with someone.
 Let us first see how Tamagoyaki are getting on with things.
 

chap7.tex

@@ -4,7 +4,6 @@
 \chapter{Week 7}
 \section{Day 1 - ``Networking with a difference''}
 \subsection{Pushing across a LAN}
-
 \index{SSH}Now we have a complete copy of our repository in another location.
 At the moment we have created this clone on the same machine that our original is.
 This isn't really a very good idea for backup purposes.
@@ -77,7 +76,6 @@ \subsection{Protocol decision}
 
 \section{Day 2 - ``Now let's work together''}
 \subsection{Pure collaboration}
-
 We are now armed with a much clearer idea of how Git works and indeed we are now in a position to actually implement the developmental model that the team of Tamagoyaki need in order to collaborate on their projects.
 It should be noted that although we have reached the point of being able to work together on a project, this is not where out discussions about Git will end.
 We still have a number of topics to cover and these will be visited as required during the subsequent implementation of Git at Tamagoyaki.
@@ -247,7 +245,6 @@ \subsection{Pure collaboration}
 
 \section{Day 3 - ``Rebasing our commitments''}
 \subsection{Rebase examples}
-
 We are now going to go back to our \texttt{coderepo} folder.
 This is the one we cloned from in Week 6 to create the \texttt{coderepo-cl} repository.
 When we left this repository, we were at commit \textbf{1c3206a}.
@@ -507,7 +504,6 @@ \subsection{Rebase examples}
 
 \section{Day 4 - ``Starting to get rebased''}
 \subsection{Using rebase with branches}
-
 \index{continuous integration}Up until now we have used \texttt{git rebase} to work on our current branch, modifying a few things here and there.
 This is actually one of the simplest things that rebase can perform, and as hinted to in our workflow design, we can actually use \texttt{git rebase} to perform something called \emph{Continuous Integration}.
 
@@ -714,7 +710,6 @@ \subsection{Using rebase with branches}
 
 \section{Day 5 - ``I could rebase the world''}
 \subsection{Migrating commits}
-
 We are almost at the end our our journey with the rebase tool and have one more stop before we start looking at other features of Git.
 
 \begin{trenches}

chap8.tex

@@ -4,7 +4,6 @@
 \chapter{Week 8}
 \section{Day 1 - ``Give a man a patch''}
 \subsection{Collaborating with outsiders}
-
 We have spoken at great length now about rebasing and have seen that it is a very very powerful tool.
 It can form part of your workflow in your development cycle.
 However, always heed that warning that should send alarm bells ringing in the back of your mind about rebasing.
@@ -295,7 +294,6 @@ \subsection{Can we have some order please?}
 
 \section{Day 2 - ``Looking for problems''}
 \subsection{A problem shared is a problem bisected}
-
 \index{bisecting}During most software development, bugs are introduced.
 Sometimes these bugs are fixed immediately and sometimes they sit there in the code festering away for months on end until someone tests a specific case.
 Of course it is always best to have test suites and run them regularly against the code base, but on occasions either the test case itself has a bug,
@@ -450,7 +448,6 @@ \subsection{A problem shared is a problem bisected}
 Notice that at the end of the bisect, Git does not return us to the master branch.
 We are left in the last tested checked out revision.
 
-
 \subsection{Automating the process}
 \index{bisecting!automation}So bisecting is a very powerful way of quickly and efficiently finding the point at which bugs were introduced or \index{regression testing}regression testing.
 Git was spot on when it suggested that that revision was the one responsible for the mistake.
@@ -555,7 +552,6 @@ \subsection{Automating the process}
 
 \section{Day 3 - ``Filtered repos''}
 \subsection{Looking at a repo with rose tinted glasses}
-
 \index{filtering}It does happen. Sometimes when people are under pressure, mistakes are made, just like earlier when we accidently deleted our branch from the repository.
 This time the mistake is a little more crucial but again it does happen and it sometimes goes a long time before it is noticed.
 
@@ -1019,7 +1015,6 @@ \subsection{Little bundles of joy}
 
 \section{Day 5 - ``Shhh....we're in a library''}
 \subsection{Nuclear fusion}
-
 OK, so we are not quite at the stage of nuclear physics, but it would be nice to know how to bring our library back into our repository.
 Git offers a tool called \indexgit{submodule}.  This tool allows you to link a remote repositories branch and store it under a subdirectory of the project.
 It does have some nuances which must be learnt, but can be very useful.