Minor edits.

en/branch.txt

@@ -16,7 +16,7 @@ With this magic word, the files in your directory suddenly shapeshift from one v
 
 === The Boss Key ===
 
-Ever play one of those games where at the push of a button ("the boss key"), the screen would instantly display a spreadsheet or something? So if the boss walked in the office while you were playing the game you could quickly hide it away?
+Ever play one of those games where at the push of a button (``the boss key''), the screen would instantly display a spreadsheet or something? So if the boss walked in the office while you were playing the game you could quickly hide it away?
 
 In some directory:
 
@@ -69,7 +69,7 @@ In other words, after checking out an old state, Git automatically puts you in a
 
 === Quick Fixes ===
 
-You're in the middle of something when you are told to drop everything and fix a newly discovered bug in commit starting with "1b6d":
+You're in the middle of something when you are told to drop everything and fix a newly discovered bug in commit `1b6d...`:
 
  $ git commit -a
  $ git checkout -b fixes 1b6d
@@ -98,23 +98,17 @@ With many version control systems, creating branches is easy but merging them
 back together is tough. With Git, merging is so trivial that you might be
 unaware of it happening.
 
-Indeed, though we have just introduced *git merge*, we encountered merging long
-ago. The *pull* command in fact fetches commits and then merges them into your
-current branch. If you have no local changes, then this merge becomes a 'fast
-forward', akin to fetching the latest version in a centralized version control
-system. But if you do have local changes, Git will automatically merge, and
-report any conflicts.
+Indeed, though we have just introduced *git merge*, we encountered merging long ago. The *pull* command in fact fetches commits and then merges them into your current branch. If you have no local changes, then the merge is a 'fast forward', a degenerate case akin to fetching the latest version in a centralized version control system. But if you do have local changes, Git will automatically merge, and report any conflicts.
 
 Ordinarily, a commit has exactly one parent, namely, the previous commit.
-Merging creates a commit with at least two parents. This begs the question:
-what commit does `HEAD~10` really refer to? A commit could have multiple
-parents, so which one do we follow?
+Merging other branches creates a commit with at least two parents. This begs
+the question: what commit does `HEAD~10` really refer to? A commit could have
+multiple parents, so which one do we follow?
 
-The answer is this notation means we follow the first parent if there is ever a
-choice. This is usually desired, because commits in the current branch always
-become first parents in a *git merge*; frequently you're only concerned with
-the changes you made in the current branch, as opposed to changes merged in
-from other branches.
+It turns out we follow the first parent at every step. This is usually desired,
+because commits in the current branch always become first parents in a *git
+merge*; frequently you're only concerned with the changes you made in the
+current branch, as opposed to changes merged in from other branches.
 
 You can refer to a specific parent with a caret. For example, to show
 the logs from the second parent:
@@ -130,7 +124,7 @@ You can combine this notation with other types. For example:
 
  $ git checkout 1bd6^^2~10 -b ancient
 
-starts a new branch "ancient" representing the state 10 commits back from the
+starts a new branch ``ancient'' representing the state 10 commits back from the
 second parent of the first parent of the commit starting with 1bd6.
 
 === Uninterrupted Workflow ===
@@ -190,24 +184,24 @@ Next, work on anything: fix bugs, add features, add temporary code, and so forth
   $ git checkout sanitized
   $ git cherry-pick medley^^
 
-applies the grandparent of the head commit of the "medley" branch to the "sanitized" branch. With appropriate cherry-picks you can construct a branch that contains only permanent code, and has related commits grouped together.
+applies the grandparent of the head commit of the ``medley'' branch to the ``sanitized'' branch. With appropriate cherry-picks you can construct a branch that contains only permanent code, and has related commits grouped together.
 
 === Managing Branches ===
 
 List all branches by typing:
 
  $ git branch
 
-By default, you start in a branch named "master". Some advocate leaving the
-"master" branch untouched and creating new branches for your own edits.
+By default, you start in a branch named ``master''. Some advocate leaving the
+``master'' branch untouched and creating new branches for your own edits.
 
 The *-d* and *-m* options allow you to delete and move (rename) branches.
 See *git help branch*.
 
-The "master" branch is a useful convention. Others may assume that your
+The ``master'' branch is a useful custom. Others may assume that your
 repository has a branch with this name, and that it contains the official
-version of your project. You can rename or obliterate the "master" branch, but
-you might as well respect this custom.
+version of your project. Although you can rename or obliterate the ``master''
+branch, you might as well respect this convention.
 
 === Temporary Branches ===
 

en/clone.txt

@@ -156,7 +156,7 @@ A `bzr-git` plugin lets Bazaar users work with Git repositories to some extent.
 
 === Why I use Git ===
 
-I originally chose Git because I heard it could manage the unimaginably unmanageable Linux kernel source. I've never since felt a need to switch. Git has served admirably, and I've yet to be bitten by its flaws. As I primarily use Linux, issues on other platforms are of no concern.
+I originally chose Git because I heard it could manage the unimaginably unmanageable Linux kernel source. I've never felt a need to switch. Git has served admirably, and I've yet to be bitten by its flaws. As I primarily use Linux, issues on other platforms are of no concern.
 
 Also, I prefer C programs and bash scripts to executables such as Python scripts: there are fewer dependencies, and I'm addicted to fast running times.
 

en/intro.txt

@@ -6,13 +6,13 @@ I'll use an analogy to introduce version control. See http://en.wikipedia.org/wi
 
 I've played computer games almost all my life. In contrast, I only started using version control systems as an adult. I suspect I'm not alone, and comparing the two may make these concepts easier to explain and understand.
 
-Think of editing your code or document, or whatever, as playing a game. Once you've made a lot of progress, you'd like to save. To do so, you click on the "Save" button in your trusty editor.
+Think of editing your code, or document, as playing a game. Once you've made a lot of progress, you'd like to save. To do so, you click on the 'Save' button in your trusty editor.
 
 But this will overwrite the old version. It's like those old school games which only had one save slot: sure you could save, but you could never go back to an older state. Which was a shame, because your previous save might have been right at an exceptionally fun part of the game that you'd like to revisit one day. Or worse still, your current save is in an unwinnable state, and you have to start again.
 
 === Version Control ===
 
-When editing, you can "Save As..." a different file, or copy the file somewhere first before saving if you want to savour old versions. You can compress them too to save space. This is a primitive and labour-intensive form of version control. Computer games improved on this long ago, many of them providing multiple automatically timestamped save slots.
+When editing, you can 'Save As...' a different file, or copy the file somewhere first before saving if you want to savour old versions. You can compress them too to save space. This is a primitive and labour-intensive form of version control. Computer games improved on this long ago, many of them providing multiple automatically timestamped save slots.
 
 Let's make the problem slightly tougher. Say you have a bunch of files that go together, such as source code for a project, or files for a website. Now if you want to keep an old version you have to archive a whole directory. Keeping many versions around by hand is inconvenient, and quickly becomes expensive.
 

en/multiplayer.txt

@@ -30,7 +30,7 @@ your web directory:
 
  $ GIT_DIR=proj.git git init
 
-In the "proj.git" directory, run:
+In the `proj.git` directory, run:
 
  $ git --bare update-server-info
  $ cp hooks/post-update.sample hooks/post-update
@@ -70,7 +70,7 @@ The receiver can even do this from an empty repository. Despite its
 size, +somefile+ contains the entire original git repository.
 
 In larger projects, eliminate waste by bundling only changes the other
-repository lacks. For example, suppose the commit "1bd6..." is the most
+repository lacks. For example, suppose the commit ``1bd6...'' is the most
 recent commit shared by both parties:
 
  $ git bundle create somefile HEAD ^1bd6
@@ -133,8 +133,8 @@ config options initialized created with the clone. Let's take a peek:
 
  $ git config --list
 
-The +remote.origin.url+ option controls the source URL; "origin" is a nickname
-given to the source repository. As with the "master" branch convention, we may
+The +remote.origin.url+ option controls the source URL; ``origin'' is a nickname
+given to the source repository. As with the ``master'' branch convention, we may
 change or delete this nickname but there is usually no reason for doing so.
 
 If the original repository moves, we can update the URL via:
@@ -180,7 +180,7 @@ logs for the appropriate SHA1 hash, but it's much easier to type:
 
  $ git diff origin/HEAD
 
-Or you can see what the "experimental" branch has been up to:
+Or you can see what the ``experimental'' branch has been up to:
 
  $ git log origin/experimental
 

en/secrets.txt

@@ -8,7 +8,7 @@ How can Git be so unobtrusive? Aside from occasional commits and merges, you can
 
 Other version control systems don't let you forget about them. Permissions of files may be read-only unless you explicitly tell the server which files you intend to edit. The central server might be keeping track of who's checked out which code, and when. When the network goes down, you'll soon suffer. Developers constantly struggle with virtual red tape and bureaucracy.
 
-The secret is the `.git` directory in your working directory. Git keeps the history of your project here. The initial "." stops it showing up in `ls` listings. Except when you're pushing and pulling changes, all version control operations operate within this directory.
+The secret is the `.git` directory in your working directory. Git keeps the history of your project here. The initial ``.'' stops it showing up in `ls` listings. Except when you're pushing and pulling changes, all version control operations operate within this directory.
 
 You have total control over the fate of your files because Git doesn't care what you do to them. Git can easily recreate a saved state from `.git` at any time.
 
@@ -20,7 +20,7 @@ A SHA1 hash can be thought of as a unique 160-bit ID number for every string of
 
 As a SHA1 hash is itself a string of bytes, we can hash strings of bytes containing other hashes. This simple observation is surprisingly useful: look up 'hash chains'. We'll later see how Git uses it to efficiently guarantee data integrity.
 
-Briefly, Git keeps your data in the ".git/objects" subdirectory, where instead of normal filenames, you'll find only IDs. By using IDs as filenames, as well as a few lockfiles and timestamping tricks, Git transforms any humble filesystem into an efficient and robust database.
+Briefly, Git keeps your data in the `.git/objects` subdirectory, where instead of normal filenames, you'll find only IDs. By using IDs as filenames, as well as a few lockfiles and timestamping tricks, Git transforms any humble filesystem into an efficient and robust database.
 
 === Intelligence ===
 
@@ -75,7 +75,7 @@ this by typing:
 Git is 'content-addressable': files are not stored according to their filename,
 but rather by the hash of the data they contain, in a file we call a 'blob
 object'. We can think of the hash as a unique ID for a file's contents, so
-in a sense we are addressing files by their content. The initial "blob 6" is
+in a sense we are addressing files by their content. The initial `blob 6` is
 merely a header consisting of the object type and its length in bytes; it
 simplifies internal bookkeeping.
 
@@ -102,7 +102,7 @@ Git gets around to the filenames during a commit:
  $ git commit  # Type some message.
  $ find .git/objects -type f
 
-You should now see 3 objects. This time I cannot tell you what the 2 new files are, as it partly depends on the filename you picked. We'll proceed assuming you chose "rose". If you didn't, you can rewrite history to make it look like you did:
+You should now see 3 objects. This time I cannot tell you what the 2 new files are, as it partly depends on the filename you picked. We'll proceed assuming you chose ``rose''. If you didn't, you can rewrite history to make it look like you did:
 
  $ git filter-branch --tree-filter 'mv YOUR_FILENAME rose'
  $ find .git/objects -type f
@@ -125,9 +125,9 @@ Hash verification is trickier via cat-file because its output contains more
 than the raw uncompressed object file.
 
 This file is a 'tree' object: a list of tuples consisting of a file
-type, a filename, and a hash. In our example, the file type is "100644", which
-means "rose" is a normal file, and the hash is the blob object that contains
-the contents of "rose". Other possible file types are executables, symlinks or
+type, a filename, and a hash. In our example, the file type is 100644, which
+means `rose` is a normal file, and the hash is the blob object that contains
+the contents of `rose'. Other possible file types are executables, symlinks or
 directories. In the last case, the hash points to a tree object.
 
 If you ran filter-branch, you'll have old objects you no longer need. Although