Copy-writing feedback

Author: ben

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

@@ -4,7 +4,7 @@
 (((Perforce)))
 Perforce is a very popular version-control system in corporate environments.
 It's been around since 1995, which makes it the oldest system covered in this chapter.
-As such, it's designed with the constraints of its day; it assumes you're always be connected to a single central server, and only one version is kept on the local disk.
+As such, it's designed with the constraints of its day; it assumes you're always connected to a single central server, and only one version is kept on the local disk.
 To be sure, its features and constraints are well-suited to several specific problems, but there are lots of projects using Perforce where Git would actually work better.
 
 There are two options if you'd like to mix your use of Perforce and Git.
@@ -22,7 +22,7 @@ Perforce provides a product called Git Fusion (available at http://www.perforce.
 For our examples, we'll be using the easiest installation method for Git Fusion, which is downloading a virtual machine that runs the Perforce daemon and Git Fusion.
 You can get the virtual machine image from http://www.perforce.com/downloads/Perforce/20-User[], and once it's finished downloading, import it into your favorite virtualization software (we'll use VirtualBox).
 
-Upon first starting the machine, it asks you to customize several the password for three Linux users (`root`, `perforce`, and `git`), and provide an instance name, which can be used to distinguish this installation from others on the same network. When that has all completed, you'll see this:
+Upon first starting the machine, it asks you to customize the password for three Linux users (`root`, `perforce`, and `git`), and provide an instance name, which can be used to distinguish this installation from others on the same network. When that has all completed, you'll see this:
 
 .The Git Fusion virtual machine boot screen.
 image::images/git-fusion-boot.png[The Git Fusion virtual machine boot screen.]
@@ -349,7 +349,7 @@ Doing initial import of //depot/www/live/ from revision #head into refs/remotes/
 ----
 
 This creates what in Git terms is a ``shallow'' clone; only the very latest Perforce revision is imported into Git; remember, Perforce isn't designed to give every revision to every user.
-This is enough to use Git as a Perforce client, but for other purposes it's not enough; see <<_shallow>> for more on this topic.
+This is enough to use Git as a Perforce client, but for other purposes it's not enough.
 
 Once it's finished, we have a fully-functional Git repository:
 

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

@@ -56,7 +56,7 @@ $ git log --all --oneline --decorate
 512e75a (HEAD, tag: TFS_C35190, origin_tfs/tfs, master) Checkin message
 ----
 
-This is called a _shallow_ clone, meaning that only the latest changeset has been downloaded (see <<_shallow>> for more on shallow clones).
+This is called a _shallow_ clone, meaning that only the latest changeset has been downloaded.
 TFVC isn't designed for each client to have a full copy of the history, so git-tf defaults to only getting the latest version, which is much faster.
 
 If you have some time, it's probably worth it to clone the entire project history, using the `--deep` option: