change all I to We

Author: schacon

book/07-git-tools/sections/debugging.asc

@@ -37,8 +37,8 @@ Another cool thing about Git is that it doesn’t track file renames explicitly.
 It records the snapshots and then tries to figure out what was renamed implicitly, after the fact.
 One of the interesting features of this is that you can ask it to figure out all sorts of code movement as well.
 If you pass `-C` to `git blame`, Git analyzes the file you’re annotating and tries to figure out where snippets of code within it originally came from if they were copied from elsewhere.
-Recently, I was refactoring a file named `GITServerHandler.m` into multiple files, one of which was `GITPackUpload.m`.
-By blaming `GITPackUpload.m` with the `-C` option, I could see where sections of the code originally came from:
+For example, say you are refactoring a file named `GITServerHandler.m` into multiple files, one of which is `GITPackUpload.m`.
+By blaming `GITPackUpload.m` with the `-C` option, you can see where sections of the code originally came from:
 
 [source,shell]
 ----

book/07-git-tools/sections/replace.asc

@@ -67,7 +67,7 @@ c6e1e95 (history) fourth commit
 c1822cf first commit
 ----
 
-I think it's useful in this case to create a base commit that has instructions on how to expand the history, so other developers know what to do if they hit the first commit in the truncated history and need more. So, what we're going to do is create an initial commit object as our base point with instructions, then rebase the remaining commits (four and five) on top of it.
+It's useful in this case to create a base commit that has instructions on how to expand the history, so other developers know what to do if they hit the first commit in the truncated history and need more. So, what we're going to do is create an initial commit object as our base point with instructions, then rebase the remaining commits (four and five) on top of it.
 
 To do that, we need to choose a point to split at, which for us is the third commit, which is `9c68fdc` in SHA-speak. So, our base commit will be based off of that tree. We can create our base commit using the `commit-tree` command, which just takes a tree and will give us a brand new, parentless commit object SHA back.
 

book/07-git-tools/sections/rerere.asc

@@ -15,7 +15,7 @@ To enable the `rerere` functionality, you simply have to run this config setting
 $ git config --global rerere.enabled true
 ----
 
-You can also turn it on by creating the `.git/rr-cache` directory in a specific repository, but I think the config setting is clearer, and it can be done globally.
+You can also turn it on by creating the `.git/rr-cache` directory in a specific repository, but the config setting is clearer and it can be done globally.
 
 Now let's see a simple example. Let's say we have a file that looks like this:
 
@@ -118,7 +118,7 @@ $ git rerere diff
  end
 ----
 
-So that basically says, when I see a hunk conflict in a `hello.rb` file that has ``hello mundo'' on one side and ``hola world'' on the other, resolve it to ``hola mundo''.
+So that basically says, when Git sees a hunk conflict in a `hello.rb` file that has ``hello mundo'' on one side and ``hola world'' on the other, it will resolve it to ``hola mundo''.
 
 Now we can mark it as resolved and commit it:
 

book/07-git-tools/sections/searching.asc

@@ -103,7 +103,7 @@ If you need to be more specific, you can provide a regular expression to search
 
 Another fairly advanced log search that is insanely useful is the line history search. This is a fairly recent addition and not very well known, but it can be really helpful. It is called with the `-L` option to `git log` and will show you the history of a function or line of code in your codebase.
 
-For example, if I wanted to see every change made to the function `git_deflate_bound` in the `zlib.c` file, I could run `git log -L :git_deflate_bound:zlib.c`. This will try to figure out what the bounds of that function are and then look through the history and show me every change that was made to the function as a series of patches back to when the function was first created.
+For example, if we wanted to see every change made to the function `git_deflate_bound` in the `zlib.c` file, we could run `git log -L :git_deflate_bound:zlib.c`. This will try to figure out what the bounds of that function are and then look through the history and show me every change that was made to the function as a series of patches back to when the function was first created.
 
 [source,shell]
 ----

book/09-git-and-other-scms/sections/client-svn.asc

@@ -29,7 +29,7 @@ If you're working with a team, and some are using SVN and others are using Git,
 To demonstrate this functionality, you need a typical SVN repository that you have write access to.
 If you want to copy these examples, you'll have to make a writeable copy of my test repository.
 In order to do that easily, you can use a tool called `svnsync` that comes with Subversion.
-For these tests, I created a new Subversion repository on Google Code that was a partial copy of the `protobuf` project, which is a tool that encodes structured data for network transmission.
+For these tests, we created a new Subversion repository on Google Code that was a partial copy of the `protobuf` project, which is a tool that encodes structured data for network transmission.
 
 To follow along, you first need to create a new local Subversion repository:
 

book/11-git-internals/1-git-internals.asc

@@ -2,9 +2,9 @@
 == Git Internals
 
 You may have skipped to this chapter from a previous chapter, or you may have gotten here after reading the rest of the book – in either case, this is where you’ll go over the inner workings and implementation of Git.
-I found that learning this information was fundamentally important to understanding how useful and powerful Git is, but others have argued to me that it can be confusing and unnecessarily complex for beginners.
-Thus, I’ve made this discussion the last chapter in the book so you could read it early or later in your learning process.
-I leave it up to you to decide.
+We found that learning this information was fundamentally important to understanding how useful and powerful Git is, but others have argued to us that it can be confusing and unnecessarily complex for beginners.
+Thus, we’ve made this discussion the last chapter in the book so you could read it early or later in your learning process.
+We leave it up to you to decide.
 
 Now that you’re here, let’s get started.
 First, if it isn’t yet clear, Git is fundamentally a content-addressable filesystem with a VCS user interface written on top of it.
@@ -38,4 +38,4 @@ This chapter has covered a number of plumbing commands – commands that are low
 Understanding how Git works at a lower level should make it easier to understand why it’s doing what it’s doing and also to write your own tools and helping scripts to make your specific workflow work for you.
 
 Git as a content-addressable filesystem is a very powerful tool that you can easily use as more than just a VCS.
-I hope you can use your newfound knowledge of Git internals to implement your own cool application of this technology and feel more comfortable using Git in more advanced ways.
+We hope you can use your newfound knowledge of Git internals to implement your own cool application of this technology and feel more comfortable using Git in more advanced ways.

book/11-git-internals/sections/objects.asc

@@ -330,7 +330,7 @@ image::images/data-model-3.png[All the objects in your Git directory.]
 
 ==== Object Storage
 
-I mentioned earlier that a header is stored with the content.
+We mentioned earlier that a header is stored with the content.
 Let’s take a minute to look at how Git stores its objects.
 You’ll see how to store a blob object – in this case, the string ``what is up, doc?'' – interactively in the Ruby scripting language.
 You can start up interactive Ruby mode with the `irb` command:

book/11-git-internals/sections/refs.asc

@@ -70,7 +70,7 @@ When you run commands like `git branch (branchname)`, Git basically runs that `u
 The question now is, when you run `git branch (branchname)`, how does Git know the SHA-1 of the last commit?
 The answer is the HEAD file.
 The HEAD file is a symbolic reference to the branch you’re currently on.
-By symbolic reference, I mean that unlike a normal reference, it doesn’t generally contain a SHA-1 value but rather a pointer to another reference.
+By symbolic reference, we mean that unlike a normal reference, it doesn’t generally contain a SHA-1 value but rather a pointer to another reference.
 If you look at the file, you’ll normally see something like this:
 
 [source,shell]