Merge pull request #213 from rdwampler/avoid-singular-pronouns

Avoid first-person singular pronouns where appropriate

Author: ben

book/02-git-basics/sections/remotes.asc

@@ -62,7 +62,7 @@ Notice that these remotes use a variety of protocols; we'll cover more about thi
 
 ==== Adding Remote Repositories
 
-I've mentioned and given some demonstrations of adding remote repositories in previous sections, but here is how to do it explicitly.(((git commands, remote)))
+We've mentioned and given some demonstrations of adding remote repositories in previous sections, but here is how to do it explicitly.(((git commands, remote)))
 To add a new remote Git repository as a shortname you can reference easily, run `git remote add [shortname] [url]`:
 
 [source,console]

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

@@ -104,7 +104,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 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.
+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 us every change that was made to the function as a series of patches back to when the function was first created.
 
 [source,console]
 ----

book/08-customizing-git/sections/attributes.asc

@@ -105,7 +105,7 @@ index 0b013ca..ba25db5 100644
  Many people's version-control method of choice is to copy files into another directory (perhaps a time-stamped directory, if they're clever). This approach is very common because it is so simple, but it is also incredibly error prone. It is easy to forget which directory you're in and accidentally write to the wrong file or copy over files you don't mean to.
 ----
 
-Git successfully and succinctly tells me that I added the string ``Testing: 1, 2, 3.'', which is correct.
+Git successfully and succinctly tells us that we added the string ``Testing: 1, 2, 3.'', which is correct.
 It's not perfect – formatting changes wouldn't show up here – but it certainly works.
 
 Another interesting problem you can solve this way involves diffing image files.

book/08-customizing-git/sections/config.asc

@@ -235,11 +235,11 @@ You can also set up a graphical merge-conflict-resolution tool instead of having
 We'll demonstrate setting up the Perforce Visual Merge Tool (P4Merge) to do your diffs and merge resolutions, because it's a nice graphical tool and it's free.
 
 If you want to try this out, P4Merge works on all major platforms, so you should be able to do so.
-I'll use path names in the examples that work on Mac and Linux systems; for Windows, you'll have to change `/usr/local/bin` to an executable path in your environment.
+We'll use path names in the examples that work on Mac and Linux systems; for Windows, you'll have to change `/usr/local/bin` to an executable path in your environment.
 
 To begin, download P4Merge from http://www.perforce.com/downloads/Perforce/[].
 Next, you'll set up external wrapper scripts to run your commands.
-I'll use the Mac path for the executable; in other systems, it will be where your `p4merge` binary is installed.
+We'll use the Mac path for the executable; in other systems, it will be where your `p4merge` binary is installed.
 Set up a merge wrapper script named `extMerge` that calls your binary with all the arguments provided:
 
 [source,console]

book/08-customizing-git/sections/hooks.asc

@@ -17,7 +17,7 @@ If you want to use the bundled hook scripts, you'll have to rename them; their f
 
 To enable a hook script, put a file in the `hooks` subdirectory of your Git directory that is named appropriately and is executable.
 From that point forward, it should be called.
-I'll cover most of the major hook filenames here.
+We'll cover most of the major hook filenames here.
 
 ==== Client-Side Hooks
 
@@ -47,7 +47,7 @@ You may use it in conjunction with a commit template to programmatically insert
 
 The `commit-msg` hook takes one parameter, which again is the path to a temporary file that contains the commit message written by the developer.
 If this script exits non-zero, Git aborts the commit process, so you can use it to validate your project state or commit message before allowing a commit to go through.
-In the last section of this chapter, I'll demonstrate using this hook to check that your commit message is conformant to a required pattern.
+In the last section of this chapter, We'll demonstrate using this hook to check that your commit message is conformant to a required pattern.
 
 After the entire commit process is completed, the `post-commit` hook runs.
 It doesn't take any parameters, but you can easily get the last commit by running `git log -1 HEAD`.

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

@@ -13,7 +13,7 @@ You'll learn more about what this means in a bit.
 In the early days of Git (mostly pre 1.5), the user interface was much more complex because it emphasized this filesystem rather than a polished VCS.
 In the last few years, the UI has been refined until it's as clean and easy to use as any system out there; but often, the stereotype lingers about the early Git UI that was complex and difficult to learn.
 
-The content-addressable filesystem layer is amazingly cool, so I'll cover that first in this chapter; then, you'll learn about the transport mechanisms and the repository maintenance tasks that you may eventually have to deal with.
+The content-addressable filesystem layer is amazingly cool, so we'll cover that first in this chapter; then, you'll learn about the transport mechanisms and the repository maintenance tasks that you may eventually have to deal with.
 
 include::sections/plumbing-porcelain.asc[]
 

book/introduction.asc

@@ -50,7 +50,7 @@ plunge.
 about Git and can wield it with power and grace, you can move on to discuss how Git stores its objects,
 what the object model is, details of packfiles, server protocols, and more. Throughout the book,
 we will refer to sections of this chapter in case you feel like diving deep at that point; 
-but if you are like me and want to dive into the technical details, you may want to read Chapter 10 first.
+but if you are like us and want to dive into the technical details, you may want to read Chapter 10 first.
 We leave that up to you.
 
 In *Appendix A* we look at a number of examples of using Git in various specific environments. We cover