Merge pull request progit#1155 from ajax333221/master

single-quote normalization

Author: ben

book/04-git-server/sections/protocols.asc

@@ -175,7 +175,7 @@ Last, like the HTTPS, Git and Local protocols, SSH is efficient, making the data
 The negative aspect of SSH is that it doesn't support anonymous access to your Git repository.
 If you're using SSH, people _must_ have SSH access to your machine, even in a read-only capacity, which doesn't make SSH conducive to open source projects for which people might simply want to clone your repository to examine it.
 If you're using it only within your corporate network, SSH may be the only protocol you need to deal with.
-If you want to allow anonymous read-only access to your projects and also want to use SSH, you’ll have to set up SSH for you to push over but something else for others to fetch from.
+If you want to allow anonymous read-only access to your projects and also want to use SSH, you'll have to set up SSH for you to push over but something else for others to fetch from.
 
 ==== The Git Protocol
 
@@ -191,7 +191,7 @@ Suffice it to say that this is rare.
 ===== The Pros
 
 The Git protocol is often the fastest network transfer protocol available.
-If you’re serving a lot of traffic for a public project or serving a very large project that doesn't require user authentication for read access, it’s likely that you'll want to set up a Git daemon to serve your project.
+If you're serving a lot of traffic for a public project or serving a very large project that doesn't require user authentication for read access, it's likely that you'll want to set up a Git daemon to serve your project.
 It uses the same data-transfer mechanism as the SSH protocol but without the encryption and authentication overhead.
 
 ===== The Cons

book/04-git-server/sections/smart-http.asc

@@ -18,7 +18,7 @@ $ a2enmod cgi alias env
 
 This also enables the `mod_cgi`, `mod_alias`, and `mod_env` modules, which are all needed for this to work properly.
 
-You’ll also need to set the Unix user group of the `/srv/git` directories to `www-data` so your web server can read- and write-access the repositories, because the Apache instance running the CGI script will (by default) be running as that user:
+You'll also need to set the Unix user group of the `/srv/git` directories to `www-data` so your web server can read- and write-access the repositories, because the Apache instance running the CGI script will (by default) be running as that user:
 
 [source,console]
 ----

book/06-github/sections/2-contributing.asc

@@ -5,7 +5,7 @@ Now that our account is set up, let's walk through some details that could be us
 ==== Forking Projects
 
 (((forking)))
-If you want to contribute to an existing project to which you don’t have push access, you can ``fork'' the project.
+If you want to contribute to an existing project to which you don't have push access, you can ``fork'' the project.
 When you ``fork'' a project, GitHub will make a copy of the project that is entirely yours; it lives in your namespace, and you can push to it.
 
 [NOTE]
@@ -14,7 +14,7 @@ Historically, the term ``fork'' has been somewhat negative in context, meaning t
 In GitHub, a ``fork'' is simply the same project in your own namespace, allowing you to make changes to a project publicly as a way to contribute in a more open manner.
 ====
 
-This way, projects don’t have to worry about adding users as collaborators to give them push access.
+This way, projects don't have to worry about adding users as collaborators to give them push access.
 People can fork a project, push to it, and contribute their changes back to the original repository by creating what's called a Pull Request, which we'll cover next.
 This opens up a discussion thread with code review, and the owner and the contributor can then communicate about the change until the owner is happy with it, at which point the owner can merge it in.
 

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

@@ -35,12 +35,12 @@ Notice that the first field is the partial SHA-1 of the commit that last modifie
 The next two fields are values extracted from that commit -- the author name and the authored date of that commit -- so you can easily see who modified that line and when.
 After that come the line number and the content of the file.
 Also note the `^1da177e4c3f4` commit lines, where the `^` prefix designates lines that were introduced in the repository's initial commit and have remained unchanged ever since.
-This is a tad confusing, because now you’ve seen at least three different ways that Git uses the `^` to modify a commit SHA-1, but that is what it means here.
+This is a tad confusing, because now you've seen at least three different ways that Git uses the `^` to modify a commit SHA-1, but that is what it means here.
 
-Another cool thing about Git is that it doesn’t track file renames explicitly.
+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.
+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.
 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:
 
@@ -70,13 +70,13 @@ Git tells you the original commit where you wrote those lines, even if it was in
 ==== Binary Search
 
 Annotating a file helps if you know where the issue is to begin with.
-If you don’t know what is breaking, and there have been dozens or hundreds of commits since the last state where you know the code worked, you’ll likely turn to `git bisect` for help.
+If you don't know what is breaking, and there have been dozens or hundreds of commits since the last state where you know the code worked, you'll likely turn to `git bisect` for help.
 The `bisect` command does a binary search through your commit history to help you identify as quickly as possible which commit introduced an issue.
 
-Let’s say you just pushed out a release of your code to a production environment, you’re getting bug reports about something that wasn’t happening in your development environment, and you can’t imagine why the code is doing that.
-You go back to your code, and it turns out you can reproduce the issue, but you can’t figure out what is going wrong.
+Let's say you just pushed out a release of your code to a production environment, you're getting bug reports about something that wasn't happening in your development environment, and you can't imagine why the code is doing that.
+You go back to your code, and it turns out you can reproduce the issue, but you can't figure out what is going wrong.
 You can _bisect_ the code to find out.
-First you run `git bisect start` to get things going, and then you use `git bisect bad` to tell the system that the current commit you’re on is broken.
+First you run `git bisect start` to get things going, and then you use `git bisect bad` to tell the system that the current commit you're on is broken.
 Then, you must tell bisect when the last known good state was, using `git bisect good <good_commit>`:
 
 [source,console]
@@ -90,7 +90,7 @@ Bisecting: 6 revisions left to test after this
 
 Git figured out that about 12 commits came between the commit you marked as the last good commit (v1.0) and the current bad version, and it checked out the middle one for you.
 At this point, you can run your test to see if the issue exists as of this commit.
-If it does, then it was introduced sometime before this middle commit; if it doesn’t, then the problem was introduced sometime after the middle commit.
+If it does, then it was introduced sometime before this middle commit; if it doesn't, then the problem was introduced sometime after the middle commit.
 It turns out there is no issue here, and you tell Git that by typing `git bisect good` and continue your journey:
 
 [source,console]
@@ -100,7 +100,7 @@ Bisecting: 3 revisions left to test after this
 [b047b02ea83310a70fd603dc8cd7a6cd13d15c04] secure this thing
 ----
 
-Now you’re on another commit, halfway between the one you just tested and your bad commit.
+Now you're on another commit, halfway between the one you just tested and your bad commit.
 You run your test again and find that this commit is broken, so you tell Git that with `git bisect bad`:
 
 [source,console]
@@ -127,7 +127,7 @@ Date:   Tue Jan 27 14:48:32 2009 -0800
 f24d3c6ebcfc639b1a3814550e62d60b8e68a8e4 M  config
 ----
 
-When you’re finished, you should run `git bisect reset` to reset your HEAD to where you were before you started, or you’ll end up in a weird state:
+When you're finished, you should run `git bisect reset` to reset your HEAD to where you were before you started, or you'll end up in a weird state:
 
 [source,console]
 ----

book/07-git-tools/sections/interactive-staging.asc

@@ -1,7 +1,7 @@
 [[_interactive_staging]]
 === Interactive Staging
 
-In this section, you’ll look at a few interactive Git commands that can help you craft your commits to include only certain combinations and parts of files.
+In this section, you'll look at a few interactive Git commands that can help you craft your commits to include only certain combinations and parts of files.
 These tools are helpful if you modify a number of files extensively, then decide that you want those changes to be partitioned into several focused commits rather than one big messy commit.
 This way, you can make sure your commits are logically separate changesets and can be reviewed easily by the developers working with you.
 
@@ -22,7 +22,7 @@ What now>
 ----
 
 You can see that this command shows you a much different view of your staging area than you're probably used to -- basically, the same information you get with `git status` but a bit more succinct and informative.
-It lists the changes you’ve staged on the left and unstaged changes on the right.
+It lists the changes you've staged on the left and unstaged changes on the right.
 
 After this comes a ``Commands'' section, which allows you to do a number of things like staging and unstaging files, staging parts of files, adding untracked files, and displaying diffs of what has been staged.
 
@@ -92,7 +92,7 @@ Revert>> [enter]
 reverted one path
 ----
 
-Looking at your Git status again, you can see that you’ve unstaged the `TODO` file:
+Looking at your Git status again, you can see that you've unstaged the `TODO` file:
 
 [source,console]
 ----
@@ -106,7 +106,7 @@ What now> s
   3:    unchanged        +5/-1 lib/simplegit.rb
 ----
 
-To see the diff of what you’ve staged, you can use the `d` or `6` (for diff) command.
+To see the diff of what you've staged, you can use the `d` or `6` (for diff) command.
 It shows you a list of your staged files, and you can select the ones for which you would like to see the staged diff.
 This is much like specifying `git diff --cached` on the command line:
 
@@ -137,7 +137,7 @@ With these basic commands, you can use the interactive add mode to deal with you
 
 ==== Staging Patches
 
-It’s also possible for Git to stage certain _parts_ of files and not the rest.
+It's also possible for Git to stage certain _parts_ of files and not the rest.
 For example, if you make two changes to your `simplegit.rb` file and want to stage one of them and not the other, doing so is very easy in Git.
 From the same interactive prompt explained in the previous section, type `p` or `5` (for patch).
 Git will ask you which files you would like to partially stage; then, for each section of the selected files, it will display hunks of the file diff and ask if you would like to stage them, one by one:
@@ -181,7 +181,7 @@ e - manually edit the current hunk
 ? - print help
 ----
 
-Generally, you’ll type `y` or `n` if you want to stage each hunk, but staging all of them in certain files or skipping a hunk decision until later can be helpful too.
+Generally, you'll type `y` or `n` if you want to stage each hunk, but staging all of them in certain files or skipping a hunk decision until later can be helpful too.
 If you stage one part of the file and leave another part unstaged, your status output will look like this:
 
 [source,console]
@@ -195,10 +195,10 @@ What now> 1
 
 The status of the `simplegit.rb` file is interesting.
 It shows you that a couple of lines are staged and a couple are unstaged.
-You’ve partially staged this file.
+You've partially staged this file.
 At this point, you can exit the interactive adding script and run `git commit` to commit the partially staged files.
 
-You also don’t need to be in interactive add mode to do the partial-file staging -- you can start the same script by using `git add -p` or `git add --patch` on the command line.
+You also don't need to be in interactive add mode to do the partial-file staging -- you can start the same script by using `git add -p` or `git add --patch` on the command line.
 
 Furthermore, you can use patch mode for partially resetting files with the `git reset --patch` command, for checking out parts of files with the `git checkout --patch` command and for stashing parts of files with the `git stash save --patch` command.
 We'll go into more details on each of these as we get to more advanced usages of these commands.