Standardized spelling, capitalization and punctuation of 'email'

Author: sean-head

book/01-introduction/sections/first-time-setup.asc

@@ -22,7 +22,7 @@ However, if you are using Git for Windows 2.x, it is `C:\Documents and Settings\
 
 ==== Your Identity
 
-The first thing you should do when you install Git is to set your user name and e-mail address.
+The first thing you should do when you install Git is to set your user name and email address.
 This is important because every Git commit uses this information, and it's immutably baked into the commits you start creating:
 
 [source,console]
@@ -32,7 +32,7 @@ $ git config --global user.email [email protected]
 ----
 
 Again, you need to do this only once if you pass the `--global` option, because then Git will always use that information for anything you do on that system.
-If you want to override this with a different name or e-mail address for specific projects, you can run the command without the `--global` option when you're in that project.
+If you want to override this with a different name or email address for specific projects, you can run the command without the `--global` option when you're in that project.
 
 Many of the GUI tools will help you do this when you first run them.
 

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

@@ -46,7 +46,7 @@ Git uses two main types of tags: lightweight and annotated.
 A lightweight tag is very much like a branch that doesn't change – it's just a pointer to a specific commit.
 
 Annotated tags, however, are stored as full objects in the Git database.
-They're checksummed; contain the tagger name, e-mail, and date; have a tagging message; and can be signed and verified with GNU Privacy Guard (GPG).
+They're checksummed; contain the tagger name, email, and date; have a tagging message; and can be signed and verified with GNU Privacy Guard (GPG).
 It's generally recommended that you create annotated tags so you can have all this information; but if you want a temporary tag or for some reason don't want to keep the other information, lightweight tags are available too.
 
 [[_annotated_tags]]

book/02-git-basics/sections/viewing-history.asc

@@ -37,7 +37,7 @@ Date:   Sat Mar 15 10:31:28 2008 -0700
 ----
 
 By default, with no arguments, `git log` lists the commits made in that repository in reverse chronological order – that is, the most recent commits show up first.
-As you can see, this command lists each commit with its SHA-1 checksum, the author's name and e-mail, the date written, and the commit message.
+As you can see, this command lists each commit with its SHA-1 checksum, the author's name and email, the date written, and the commit message.
 
 A huge number and variety of options to the `git log` command are available to show you exactly what you're looking for.
 Here, we'll show you some of the most popular.
@@ -170,7 +170,7 @@ a11bef0 - Scott Chacon, 6 years ago : first commit
 | `%P`     | Parent hashes
 | `%p`     | Abbreviated parent hashes
 | `%an`    | Author name
-| `%ae`    | Author e-mail
+| `%ae`    | Author email
 | `%ad`    | Author date (format respects the --date=option)
 | `%ar`    | Author date, relative
 | `%cn`    | Committer name

book/04-git-server/sections/generating-ssh-key.asc

@@ -38,7 +38,7 @@ d0:82:24:8e:d7:f1:bb:9b:33:53:96:93:49:da:9b:e3 [email protected]
 First it confirms where you want to save the key (`.ssh/id_rsa`), and then it asks twice for a passphrase, which you can leave empty if you don't want to type a password when you use the key.
 
 Now, each user that does this has to send their public key to you or whoever is administrating the Git server (assuming you're using an SSH server setup that requires public keys).
-All they have to do is copy the contents of the `.pub` file and e-mail it.
+All they have to do is copy the contents of the `.pub` file and email it.
 The public keys look something like this:
 
 [source,console]

book/05-distributed-git/sections/contributing.asc

@@ -345,7 +345,7 @@ To jessica@githost:simplegit.git
  * [new branch]      featureA -> featureA
 -----
 
-Jessica e-mails John to tell him that she's pushed some work into a branch named `featureA` and he can look at it now.
+Jessica emails John to tell him that she's pushed some work into a branch named `featureA` and he can look at it now.
 While she waits for feedback from John, Jessica decides to start working on `featureB` with Josie.
 To begin, she starts a new feature branch, basing it off the server's `master` branch:
 
@@ -376,7 +376,7 @@ Jessica's repository looks like this:
 .Jessica's initial commit history.
 image::images/managed-team-1.png[Jessica's initial commit history.]
 
-She's ready to push up her work, but gets an e-mail from Josie that a branch with some initial work on it was already pushed to the server as `featureBee`.
+She's ready to push up her work, but gets an email from Josie that a branch with some initial work on it was already pushed to the server as `featureBee`.
 Jessica first needs to merge those changes in with her own before she can push to the server.
 She can then fetch Josie's changes down with `git fetch`:
 
@@ -414,7 +414,7 @@ This is called a _refspec_.
 See <<_refspec>> for a more detailed discussion of Git refspecs and different things you can do with them.
 Also notice the `-u` flag; this is short for `--set-upstream`, which configures the branches for easier pushing and pulling later.
 
-Next, John e-mails Jessica to say he's pushed some changes to the `featureA` branch and asks her to verify them.
+Next, John emails Jessica to say he's pushed some changes to the `featureA` branch and asks her to verify them.
 She runs a `git fetch` to pull down those changes:
 
 [source,console]
@@ -489,7 +489,7 @@ Contributing to public projects is a bit different.
 Because you don't have the permissions to directly update branches on the project, you have to get the work to the maintainers some other way.
 This first example describes contributing via forking on Git hosts that support easy forking.
 Many hosting sites support this (including GitHub, BitBucket, Google Code, repo.or.cz, and others), and many project maintainers expect this style of contribution.
-The next section deals with projects that prefer to accept contributed patches via e-mail.
+The next section deals with projects that prefer to accept contributed patches via email.
 
 First, you'll probably want to clone the main repository, create a topic branch for the patch or patch series you're planning to contribute, and do your work there.
 The sequence looks basically like this:
@@ -530,7 +530,7 @@ $ git push -u myfork featureA
 
 (((git commands, request-pull)))
 When your work has been pushed up to your fork, you need to notify the maintainer.
-This is often called a pull request, and you can either generate it via the website – GitHub has its own Pull Request mechanism that we'll go over in <<_github>> – or you can run the `git request-pull` command and e-mail the output to the project maintainer manually.
+This is often called a pull request, and you can either generate it via the website – GitHub has its own Pull Request mechanism that we'll go over in <<_github>> – or you can run the `git request-pull` command and email the output to the project maintainer manually.
 
 The `request-pull` command takes the base branch into which you want your topic branch pulled and the Git repository URL you want them to pull from, and outputs a summary of all the changes you're asking to be pulled in.
 For instance, if Jessica wants to send John a pull request, and she's done two commits on the topic branch she just pushed up, she can run this:
@@ -618,15 +618,15 @@ Now you can send the maintainer a message that you've made the requested changes
 image::images/public-small-3.png[Commit history after `featureBv2` work.]
 
 [[_project_over_email]]
-==== Public Project over E-Mail
+==== Public Project over Email
 
 (((contributing, public large project)))
 Many projects have established procedures for accepting patches – you'll need to check the specific rules for each project, because they will differ.
 Since there are several older, larger projects which accept patches via a developer mailing list, we'll go over an example of that now.
 
 The workflow is similar to the previous use case – you create topic branches for each patch series you work on.
 The difference is how you submit them to the project.
-Instead of forking the project and pushing to your own writable version, you generate e-mail versions of each commit series and e-mail them to the developer mailing list:
+Instead of forking the project and pushing to your own writable version, you generate email versions of each commit series and email them to the developer mailing list:
 
 [source,console]
 -----
@@ -639,8 +639,8 @@ $ git commit
 
 (((git commands, format-patch)))
 Now you have two commits that you want to send to the mailing list.
-You use `git format-patch` to generate the mbox-formatted files that you can e-mail to the list – it turns each commit into an e-mail message with the first line of the commit message as the subject and the rest of the message plus the patch that the commit introduces as the body.
-The nice thing about this is that applying a patch from an e-mail generated with `format-patch` preserves all the commit information properly.
+You use `git format-patch` to generate the mbox-formatted files that you can email to the list – it turns each commit into an email message with the first line of the commit message as the subject and the rest of the message plus the patch that the commit introduces as the body.
+The nice thing about this is that applying a patch from an email generated with `format-patch` preserves all the commit information properly.
 
 [source,console]
 -----
@@ -684,13 +684,13 @@ index 76f47bc..f9815f1 100644
 2.1.0
 -----
 
-You can also edit these patch files to add more information for the e-mail list that you don't want to show up in the commit message.
+You can also edit these patch files to add more information for the email list that you don't want to show up in the commit message.
 If you add text between the `---` line and the beginning of the patch (the `diff --git` line), then developers can read it; but applying the patch excludes it.
 
-To e-mail this to a mailing list, you can either paste the file into your e-mail program or send it via a command-line program.
+To email this to a mailing list, you can either paste the file into your email program or send it via a command-line program.
 Pasting the text often causes formatting issues, especially with ``smarter'' clients that don't preserve newlines and other whitespace appropriately.
 Luckily, Git provides a tool to help you send properly formatted patches via IMAP, which may be easier for you.
-We'll demonstrate how to send a patch via Gmail, which happens to be the e-mail agent we know best; you can read detailed instructions for a number of mail programs at the end of the aforementioned `Documentation/SubmittingPatches` file in the Git source code.
+We'll demonstrate how to send a patch via Gmail, which happens to be the email agent we know best; you can read detailed instructions for a number of mail programs at the end of the aforementioned `Documentation/SubmittingPatches` file in the Git source code.
 
 (((git commands, config)))(((email)))
 First, you need to set up the imap section in your `~/.gitconfig` file.

book/05-distributed-git/sections/distributed-workflows.asc

@@ -46,7 +46,7 @@ The process works as follows (see <<wfdiag_b>>):
 1.  The project maintainer pushes to their public repository.
 2.  A contributor clones that repository and makes changes.
 3.  The contributor pushes to their own public copy.
-4.  The contributor sends the maintainer an e-mail asking them to pull changes.
+4.  The contributor sends the maintainer an email asking them to pull changes.
 5.  The maintainer adds the contributor's repo as a remote and merges locally.
 6.  The maintainer pushes merged changes to the main repository.
 

book/05-distributed-git/sections/maintaining.asc

@@ -2,7 +2,7 @@
 
 (((maintaining a project)))
 In addition to knowing how to effectively contribute to a project, you'll likely need to know how to maintain one.
-This can consist of accepting and applying patches generated via `format-patch` and e-mailed to you, or integrating changes in remote branches for repositories you've added as remotes to your project.
+This can consist of accepting and applying patches generated via `format-patch` and emailed to you, or integrating changes in remote branches for repositories you've added as remotes to your project.
 Whether you maintain a canonical repository or want to help by verifying or approving patches, you need to know how to accept work in a way that is clearest for other contributors and sustainable by you over the long run.
 
 ==== Working in Topic Branches
@@ -29,11 +29,11 @@ $ git checkout -b sc/ruby_client master
 Now you're ready to add your contributed work into this topic branch and determine if you want to merge it into your longer-term branches.
 
 [[_patches_from_email]]
-==== Applying Patches from E-mail
+==== Applying Patches from Email
 
 (((email, applying patches from)))
-If you receive a patch over e-mail that you need to integrate into your project, you need to apply the patch in your topic branch to evaluate it.
-There are two ways to apply an e-mailed patch: with `git apply` or with `git am`.
+If you receive a patch over email that you need to integrate into your project, you need to apply the patch in your topic branch to evaluate it.
+There are two ways to apply an emailed patch: with `git apply` or with `git am`.
 
 ===== Applying a Patch with apply
 
@@ -74,7 +74,7 @@ If you can, encourage your contributors to use `format-patch` instead of `diff`
 You should only have to use `git apply` for legacy patches and things like that.
 
 To apply a patch generated by `format-patch`, you use `git am`.
-Technically, `git am` is built to read an mbox file, which is a simple, plain-text format for storing one or more e-mail messages in one text file.
+Technically, `git am` is built to read an mbox file, which is a simple, plain-text format for storing one or more email messages in one text file.
 It looks something like this:
 
 [source,console]
@@ -88,9 +88,9 @@ Limit log functionality to the first 20
 -----
 
 This is the beginning of the output of the format-patch command that you saw in the previous section.
-This is also a valid mbox e-mail format.
-If someone has e-mailed you the patch properly using git send-email, and you download that into an mbox format, then you can point git am to that mbox file, and it will start applying all the patches it sees.
-If you run a mail client that can save several e-mails out in mbox format, you can save entire patch series into a file and then use git am to apply them one at a time.
+This is also a valid mbox email format.
+If someone has emailed you the patch properly using git send-email, and you download that into an mbox format, then you can point git am to that mbox file, and it will start applying all the patches it sees.
+If you run a mail client that can save several emails out in mbox format, you can save entire patch series into a file and then use git am to apply them one at a time.
 
 However, if someone uploaded a patch file generated via `format-patch` to a ticketing system or something similar, you can save the file locally and then pass that file saved on your disk to `git am` to apply it:
 
@@ -101,7 +101,7 @@ Applying: add limit to log function
 -----
 
 You can see that it applied cleanly and automatically created the new commit for you.
-The author information is taken from the e-mail's `From` and `Date` headers, and the message of the commit is taken from the `Subject` and body (before the patch) of the e-mail.
+The author information is taken from the email's `From` and `Date` headers, and the message of the commit is taken from the `Subject` and body (before the patch) of the email.
 For example, if this patch was applied from the mbox example above, the commit generated would look something like this:
 
 -----
@@ -187,7 +187,7 @@ When all the patches for your topic are applied and committed into your branch,
 (((branches, remote)))
 If your contribution came from a Git user who set up their own repository, pushed a number of changes into it, and then sent you the URL to the repository and the name of the remote branch the changes are in, you can add them as a remote and do merges locally.
 
-For instance, if Jessica sends you an e-mail saying that she has a great new feature in the `ruby-client` branch of her repository, you can test it by adding the remote and checking out that branch locally:
+For instance, if Jessica sends you an email saying that she has a great new feature in the `ruby-client` branch of her repository, you can test it by adding the remote and checking out that branch locally:
 
 [source,console]
 -----
@@ -196,10 +196,10 @@ $ git fetch jessica
 $ git checkout -b rubyclient jessica/ruby-client
 -----
 
-If she e-mails you again later with another branch containing another great feature, you can fetch and check out because you already have the remote setup.
+If she emails you again later with another branch containing another great feature, you can fetch and check out because you already have the remote setup.
 
 This is most useful if you're working with a person consistently.
-If someone only has a single patch to contribute once in a while, then accepting it over e-mail may be less time consuming than requiring everyone to run their own server and having to continually add and remove remotes to get a few patches.
+If someone only has a single patch to contribute once in a while, then accepting it over email may be less time consuming than requiring everyone to run their own server and having to continually add and remove remotes to get a few patches.
 You're also unlikely to want to have hundreds of remotes, each for someone who contributes only a patch or two.
 However, scripts and hosted services may make this easier – it depends largely on how you develop and how your contributors develop.
 
@@ -514,14 +514,14 @@ You can also create a zip archive in much the same way, but by passing the `--fo
 $ git archive master --prefix='project/' --format=zip > `git describe master`.zip
 -----
 
-You now have a nice tarball and a zip archive of your project release that you can upload to your website or e-mail to people.
+You now have a nice tarball and a zip archive of your project release that you can upload to your website or email to people.
 
 [[_the_shortlog]]
 ==== The Shortlog
 
 (((git commands, shortlog)))
-It's time to e-mail your mailing list of people who want to know what's happening in your project.
-A nice way of quickly getting a sort of changelog of what has been added to your project since your last release or e-mail is to use the `git shortlog` command.
+It's time to email your mailing list of people who want to know what's happening in your project.
+A nice way of quickly getting a sort of changelog of what has been added to your project since your last release or email is to use the `git shortlog` command.
 It summarizes all the commits in the range you give it; for example, the following gives you a summary of all the commits since your last release, if your last release was named v1.0.1:
 
 [source,console]
@@ -542,4 +542,4 @@ Tom Preston-Werner (4):
       Regenerated gemspec for version 1.0.2
 -----
 
-You get a clean summary of all the commits since v1.0.1, grouped by author, that you can e-mail to your list.
+You get a clean summary of all the commits since v1.0.1, grouped by author, that you can email to your list.