Typographic fixes around double quotes.

8 files changed, 39 insertions, 39 deletions

diff --git a/wiki/git/config.md b/wiki/git/config.md
index 511542a..9ee058b 100644
--- a/wiki/git/config.md
+++ b/wiki/git/config.md
@@ -13,7 +13,7 @@ Full documentation is under `git help config`, unless otherwise stated.
 * `git config push.default simple` - the default behaviour (called `matching`)
   of an unqualified `git push` is to identify pairs of branches by name and
   push all matches from your local repository to the remote. Given that
-  branches have explicit "upstream" configuration identifying which, if any,
+  branches have explicit “upstream” configuration identifying which, if any,
   branch in which, if any, remote they're associated with, this is dumb. The
   `simple` mode pushes the current branch to its upstream remote, if and only
   if the local branch name and the remote branch name match _and_ the local
@@ -29,7 +29,7 @@ Full documentation is under `git help config`, unless otherwise stated.
 * `git config rebase.autosquash true` - causes `git rebase -i` to parse magic
   comments created by `git commit --squash=some-hash` and `git commit
   --fixup=some-hash` and reorder the commit list before presenting it for
-  further editing. See the descriptions of "squash" and "fixup" in `git help
+  further editing. See the descriptions of “squash” and “fixup” in `git help
   rebase` for details; autosquash makes amending commits other than the most
   recent easier and less error-prone.
 
@@ -40,10 +40,10 @@ Full documentation is under `git help config`, unless otherwise stated.
   `always`) this only happens when the start point is a remote-tracking
   branch.
 
-* `git config rerere.enabled true` - enable "reuse recorded resolution". The
+* `git config rerere.enabled true` - enable “reuse recorded resolution.” The
   `git help rerere` docs explain it pretty well, but the short version is that
-  git can record how you resolve conflicts during a "test" merge and reuse the
-  same approach when resolving the same conflict later, in a "real" merge.
+  git can record how you resolve conflicts during a “test” merge and reuse the
+  same approach when resolving the same conflict later, in a “real” merge.
 
 ## For advanced users
 
@@ -52,7 +52,7 @@ you no longer need them.
 
 * `git config advice.detachedHead` - if you already understand the difference
   between having a branch checked out and having a commit checked out, and
-  already understand what "detatched head" means, the warning on every `git
+  already understand what “detatched head” means, the warning on every `git
   checkout ...some detatched thing...` isn't helping anyone. This is also
   useful repositories used for deployment, where specific commits (from tags,
   for example) are regularly checked out.
diff --git a/wiki/git/pull-request-workflow.md b/wiki/git/pull-request-workflow.md
index 2d7e216..700eeb6 100644
--- a/wiki/git/pull-request-workflow.md
+++ b/wiki/git/pull-request-workflow.md
@@ -69,7 +69,7 @@ If you need my help here, stop now.
 
 If you find yourself needing something that's been added upstream, use
 _rebase_ to integrate it to avoid littering your feature branch with
-"meaningless" merge commits.
+“meaningless” merge commits.
 
     git checkout my-feature
     git fetch upstream
@@ -77,7 +77,7 @@ _rebase_ to integrate it to avoid littering your feature branch with
 
 ### Publish your branch
 
-When you're "done", publish your branch to your personal repository:
+When you're “done,” publish your branch to your personal repository:
 
     git push origin my-feature
 
diff --git a/wiki/git/scratch.md b/wiki/git/scratch.md
index 61d2815..a26c98f 100644
--- a/wiki/git/scratch.md
+++ b/wiki/git/scratch.md
@@ -6,7 +6,7 @@ Git repos are stored in .git:
 
     fakegit$ mkdir .git
 
-They have a "symbolic ref" (which are text files, see [`man
+They have a “symbolic ref” (which are text files, see [`man
 git-symbolic-ref`](http://jk.gs/git-symbolic-ref.html)) named `HEAD`, pointing
 to the currently checked-out branch. Let's use `master`. Branches are refs
 under `refs/heads` (see [`man git-branch`](http://jk.gs/git-branch.html)):
@@ -46,10 +46,10 @@ Does it work?
 Should you do this? **Of course not.** Anywhere you could run these commands,
 you could instead run `git init` or `git clone`, which set up a number of
 other structures, including `.git/config` and any unusual permissions options.
-The key part here is that a directory's identity as "a git repository" is
+The key part here is that a directory's identity as “a git repository” is
 entirely a function of its contents, not of having been blessed into being by
 `git` itself.
 
-You can infer a lot from this: for example, you can infer that it's "safe" to
+You can infer a lot from this: for example, you can infer that it's “safe” to
 move git repositories around using FS tools, or to back them up with the same
 tools, for example. This is not as obvious to everyone as you might hope; people 
diff --git a/wiki/git/stop-using-git-pull-to-deploy.md b/wiki/git/stop-using-git-pull-to-deploy.md
index b9021bb..078c95b 100644
--- a/wiki/git/stop-using-git-pull-to-deploy.md
+++ b/wiki/git/stop-using-git-pull-to-deploy.md
@@ -3,13 +3,13 @@
 ## The problem
 
 * You have a Git repository containing your project.
-* You want to "deploy" that code when it changes.
+* You want to “deploy” that code when it changes.
 * You'd rather not download the entire project from scratch for each
   deployment.
 
 ## The antipattern
 
-"I know, I'll use `git pull` in my deployment script!"
+“I know, I'll use `git pull` in my deployment script!”
 
 Stop doing this. Stop teaching other people to do this. It's wrong, and it
 will eventually lead to deploying something you didn't want.
@@ -32,7 +32,7 @@ the intended deployment tree. Local changes (intentional or otherwise) will be
 preserved (and merged) into the deployment, for example; once this happens,
 the actual deployed commit will _never_ match the intended commit.
 
-`git pull` will approximate the right thing "by accident": if the current
+`git pull` will approximate the right thing “by accident”: if the current
 local branch (generally `master`) for people using `git pull` is always clean,
 and always tracks the desired deployment branch, then `git pull` will update
 to the intended commit exactly. This is pretty fragile, though; many git
@@ -65,7 +65,7 @@ Quoting [Sitaram Chamarty](http://gitolite.com/the-list-and-irc/deploy.html):
 >     Again, some people might want to detect this and abort the deployment.
 
 Sitaram's own documentation talks about how to accomplish these when
-"deploying" straight out of a bare repository. That's unwise (not to mention
+“deploying” straight out of a bare repository. That's unwise (not to mention
 impractical) in most cases; deployment should use a dedicated clone of the
 canonical repository.
 
diff --git a/wiki/git/survival.md b/wiki/git/survival.md
index d7a79c1..60d1b62 100644
--- a/wiki/git/survival.md
+++ b/wiki/git/survival.md
@@ -3,7 +3,7 @@
 I think the `git` UI is pretty awful, and encourages using Git in ways that
 will screw you. Here are a few things I've picked up that have saved my bacon.
 
-* You will inevitably need to understand Git's "internals" to make use of it
+* You will inevitably need to understand Git's “internals” to make use of it
   as an SCM tool. Accept this early. If you think your SCM tool should not
   expose you to so much plumbing, [don't](http://mercurial.selenic.com)
   [use](http://bazaar.canonical.com) [Git](http://subversion.apache.org).
@@ -23,7 +23,7 @@ will screw you. Here are a few things I've picked up that have saved my bacon.
   integrate upstream changes into topic branches. The resulting history can be
   very confusing to follow, especially if you integrate upstream changes
   frequently.
-    * You can leave topic branches "out of date" relatively safely. You can do
+    * You can leave topic branches “real” relatively safely. You can do
       a test merge to see if they still work cleanly post-integration without
       actually integrating upstream into the branch permanently.
     * You can use `git rebase` or `git pull --rebase` to transplant your
@@ -47,10 +47,10 @@ will screw you. Here are a few things I've picked up that have saved my bacon.
         git branch -D test-merge-foo
 
     You can combine this with `git rerere` to save time resolving conflicts in
-    a later "real", permanent merge.
+    a later “real,” permanent merge.
 
 * You can use `git checkout -p` to build new, tidy commits out of a branch
-  laden with "wip" commits:
+  laden with “wip” commits:
 
         git fetch
         git checkout $(git merge-base origin/master foo) -b foo-cleaner-history
@@ -67,7 +67,7 @@ will screw you. Here are a few things I've picked up that have saved my bacon.
     * Gotcha: The new, clean branch must diverge from its upstream branch
       (`origin/master`, in the example above) at exactly the same point, or
       the diffs presented by `git checkout -p foo` will include chunks that
-      revert changes on the upstream branch since the "dirty" branch was
+      revert changes on the upstream branch since the “dirty” branch was
       created. The easiest way to find this point is with `git merge-base`.
 
 ## Useful Resources
diff --git a/wiki/git/theory-and-practice/index.md b/wiki/git/theory-and-practice/index.md
index 03615de..f257b12 100644
--- a/wiki/git/theory-and-practice/index.md
+++ b/wiki/git/theory-and-practice/index.md
@@ -1,6 +1,6 @@
 # Git Internals 101
 
-Yeah, yeah, another article about "how Git works". There are tons of these
+Yeah, yeah, another article about “how Git works.” There are tons of these
 already. Personally, I'm fond of Sitaram Chamarty's [fantastic series of
 articles](http://gitolite.com/master-toc.html) explaining Git from both ends,
 and of [Git for Computer
@@ -8,22 +8,22 @@ Scientists](http://eagain.net/articles/git-for-computer-scientists/). Maybe
 you'd rather read those.
 
 This page was inspired by very specific, recurring issues I've run into while
-helping people use Git. I think Git's "porcelain" layer -- its user interface
+helping people use Git. I think Git's “porcelain” layer -- its user interface
 -- is terrible, and does a bad job of insulating non-expert users from Git's
 internals. While I'd love to fix that (and I do contribute to discussions on
 that front, too), we still have the `git(1)` UI right now and people still get
 into trouble with it right now.
 
 Git follows the New Jersey approach laid out in Richard Gabriel's [The Rise of
-"Worse is Better"](http://www.dreamsongs.com/RiseOfWorseIsBetter.html): given
+“Worse is Better”](http://www.dreamsongs.com/RiseOfWorseIsBetter.html): given
 the choice between a simple implementation and a simple interface, Git chooses
 the simple implementation almost everywhere. This internal simplicity can give
 users the leverage to fix the problems that its horrible user interface leads
 them into, so these pages will focus on explaining the simple parts and giving
 users the tools to examine them.
 
-Throughout these articles, I've written "Git does X" a lot. Git is
-_incredibly_ configurable; read that as "Git does X _by default_". I'll try to
+Throughout these articles, I've written “Git does X” a lot. Git is
+_incredibly_ configurable; read that as “Git does X _by default_.” I'll try to
 call out relevant configuration options as I go, where it doesn't interrupt
 the flow of knowledge.
 
@@ -39,4 +39,4 @@ out there and that you won't need this knowledge, well, you will. You can
 either learn it during a quiet time, when you can think and experiment, or you
 can learn it when something's gone wrong, and everyone's shouting at each
 other. Git's high-level interface doesn't do much to keep you on the sensible
-path, and you will eventually need to fix something.
\ No newline at end of file
+path, and you will eventually need to fix something.
diff --git a/wiki/git/theory-and-practice/objects.md b/wiki/git/theory-and-practice/objects.md
index 985e5dd..1ad3f26 100644
--- a/wiki/git/theory-and-practice/objects.md
+++ b/wiki/git/theory-and-practice/objects.md
@@ -1,7 +1,7 @@
 # Objects
 
 Git's basest level is a storage and naming system for things Git calls
-"objects". These objects hold the bulk of the data about files and projects
+“objects.” These objects hold the bulk of the data about files and projects
 tracked by Git: file contents, directory trees, commits, and so on. Every
 object is identified by a SHA-1 hash, which is derived from its contents.
 
@@ -54,8 +54,8 @@ system. Revisions and their history are represented by `commit` objects, which c
 
     * The SHA-1 hash of the root `tree` object of the commit,
     * Zero or more SHA-1 hashes for parent commits,
-    * The name and email address of the commit's "author",
-    * The name and email address of the commit's "committer",
+    * The name and email address of the commit's “author,”
+    * The name and email address of the commit's “committer,”
     * Timestamps representing when the commit was authored and committed, and
     * A commit message.
 
@@ -67,9 +67,9 @@ predictable order determined by the `git checkout` and `git merge` commands.
 
 ## Tags
 
-Git's revision-tracking system supports "tags", which are stable names for
+Git's revision-tracking system supports “tags,” which are stable names for
 specific configurations. It also, uniquely, supports a concept called an
-"annotated tag", represented by the `tag` object type. These annotated tag
+“annotated tag,” represented by the `tag` object type. These annotated tag
 objects contain
 
     * The type and SHA-1 hash of another object,
@@ -106,8 +106,8 @@ for providing stable, meaningful names for commits.
 
 ## Storage
 
-Objects are stored in two places in Git: as "loose objects", and in "pack
-files". Newly-created objects are initially loose objects, for ease of
+Objects are stored in two places in Git: as “loose objects,” and in “pack
+files.” Newly-created objects are initially loose objects, for ease of
 manipulation; transferring objects to another repository or running certain
 administrative commands can cause them to be placed in pack files for faster
 transfer and for smaller storage.
diff --git a/wiki/git/theory-and-practice/refs-and-names.md b/wiki/git/theory-and-practice/refs-and-names.md
index 45f58f2..025ae88 100644
--- a/wiki/git/theory-and-practice/refs-and-names.md
+++ b/wiki/git/theory-and-practice/refs-and-names.md
@@ -2,15 +2,15 @@
 
 Git's [object system](objects) stores most of the data for projects tracked in
 Git, but only provides SHA-1 hashes. This is basically useless if you want to
-make practical use of Git, so Git also has a naming mechanism called "refs"
+make practical use of Git, so Git also has a naming mechanism called “refs”
 that provide human-meaningful names for objects.
 
 There are two kinds of refs:
 
-* "Normal" refs, which are names that resolve directly to SHA-1 hashes. These
+* “Normal” refs, which are names that resolve directly to SHA-1 hashes. These
   are the vast majority of refs in most repositories.
 
-* "Symbolic" refs, which are names that resolve to other refs. In most
+* “Symbolic” refs, which are names that resolve to other refs. In most
   repositories, only a few of these appear. (Circular references are possible
   with symbolic refs. Git will refuse to resolve these.)
 
@@ -27,7 +27,7 @@ namespace convention. The following namespaces are common:
 * `refs/heads/NAME`: branches. The branch name is the ref name with
   `refs/heads/` removed. Names generally point to commits.
 
-* `refs/remotes/REMOTE/NAME`: "remote-tracking" branches. These are maintained
+* `refs/remotes/REMOTE/NAME`: “remote-tracking” branches. These are maintained
   in tandem by `git remote` and `git fetch`, to cache the state of other
   repositories. Names generally point to commits.
 
@@ -54,7 +54,7 @@ rather than sanity-checking the ref before using it.
 There are a handful of special refs used by Git commands for their own
 operation. These refs do _not_ begin with `refs/`:
 
-* `HEAD`: the "current" commit for most operations. This is set when checking
+* `HEAD`: the “current” commit for most operations. This is set when checking
   out a commit, and many revision-related commands default to `HEAD` if not
   given a revision to operate on. `HEAD` can either be a symbolic ref
   (pointing to a branch ref) or a normal ref (pointing directly to a commit),
@@ -91,4 +91,4 @@ The following commands can be used to manipulate refs directly:
   pointing to `<target>`.
 
 Additionally, you can see what ref a given name resolves to using `git
-rev-parse --symbolic-full-name <name>` or `git show-ref <name>`.
\ No newline at end of file
+rev-parse --symbolic-full-name <name>` or `git show-ref <name>`.