Typographic fixes around double quotes.

3 files changed, 19 insertions, 19 deletions

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>`.