Merge pull request #499 from crd/filename_consistency

Make examples that refer to files by name consistent

Author: ben

book/02-git-basics/sections/recording-changes.asc

@@ -86,7 +86,7 @@ The `git add` command takes a path name for either a file or a directory; if it'
 ==== Staging Modified Files
 
 Let's change a file that was already tracked.
-If you change a previously tracked file called ``CONTRIBUTING.md'' and then run your `git status` command again, you get something that looks like this:
+If you change a previously tracked file called `CONTRIBUTING.md` and then run your `git status` command again, you get something that looks like this:
 
 [source,console]
 ----
@@ -105,11 +105,11 @@ Changes not staged for commit:
 
 ----
 
-The ``CONTRIBUTING.md'' file appears under a section named ``Changes not staged for commit'' – which means that a file that is tracked has been modified in the working directory but not yet staged.
+The `CONTRIBUTING.md` file appears under a section named ``Changes not staged for commit'' – which means that a file that is tracked has been modified in the working directory but not yet staged.
 To stage it, you run the `git add` command.
 `git add` is a multipurpose command – you use it to begin tracking new files, to stage files, and to do other things like marking merge-conflicted files as resolved.
 It may be helpful to think of it more as ``add this content to the next commit'' rather than ``add this file to the project''.(((git commands, add)))
-Let's run `git add` now to stage the ``CONTRIBUTING.md'' file, and then run `git status` again:
+Let's run `git add` now to stage the `CONTRIBUTING.md` file, and then run `git status` again:
 
 [source,console]
 ----
@@ -465,7 +465,7 @@ $ git commit -a -m 'added new benchmarks'
  1 file changed, 5 insertions(+), 0 deletions(-)
 ----
 
-Notice how you don't have to run `git add` on the ``CONTRIBUTING.md'' file in this case before you commit.
+Notice how you don't have to run `git add` on the `CONTRIBUTING.md` file in this case before you commit.
 
 [[_removing_files]]
 ==== Removing Files

book/07-git-tools/sections/rewriting-history.asc

@@ -273,7 +273,7 @@ This occurs fairly commonly.
 Someone accidentally commits a huge binary file with a thoughtless `git add .`, and you want to remove it everywhere.
 Perhaps you accidentally committed a file that contained a password, and you want to make your project open source.
 `filter-branch` is the tool you probably want to use to scrub your entire history.
-To remove a file named passwords.txt from your entire history, you can use the `--tree-filter` option to `filter-branch`:
+To remove a file named `passwords.txt` from your entire history, you can use the `--tree-filter` option to `filter-branch`:
 
 [source,console]
 ----
@@ -283,7 +283,7 @@ Ref 'refs/heads/master' was rewritten
 ----
 
 The `--tree-filter` option runs the specified command after each checkout of the project and then recommits the results.
-In this case, you remove a file called passwords.txt from every snapshot, whether it exists or not.
+In this case, you remove a file called `passwords.txt` from every snapshot, whether it exists or not.
 If you want to remove all accidentally committed editor backup files, you can run something like `git filter-branch --tree-filter 'rm -f *~' HEAD`.
 
 You’ll be able to watch Git rewriting trees and commits and then move the branch pointer at the end.
@@ -292,7 +292,7 @@ To run `filter-branch` on all your branches, you can pass `--all` to the command
 
 ===== Making a Subdirectory the New Root
 
-Suppose you’ve done an import from another source control system and have subdirectories that make no sense (trunk, tags, and so on).
+Suppose you’ve done an import from another source control system and have subdirectories that make no sense (`trunk`, `tags`, and so on).
 If you want to make the `trunk` subdirectory be the new project root for every commit, `filter-branch` can help you do that, too:
 
 [source,console]

book/09-git-and-other-scms/sections/import-svn.asc

@@ -28,7 +28,7 @@ $ svn log --xml | grep author | sort -u | \
 
 That generates the log output in XML format, then keeps only the lines with author information, discards duplicates, strips out the XML tags.
 (Obviously this only works on a machine with `grep`, `sort`, and `perl` installed.)
-Then, redirect that output into your users.txt file so you can add the equivalent Git user data next to each entry.
+Then, redirect that output into your `users.txt` file so you can add the equivalent Git user data next to each entry.
 
 You can provide this file to `git svn` to help it map the author data more accurately.
 You can also tell `git svn` not to include the metadata that Subversion normally imports, by passing `--no-metadata` to the `clone` or `init` command.

book/10-git-internals/sections/objects.asc

@@ -149,8 +149,8 @@ image::images/data-model-1.png[Simple version of the Git data model.]
 You can fairly easily create your own tree.
 Git normally creates a tree by taking the state of your staging area or index and writing a series of tree objects from it.
 So, to create a tree object, you first have to set up an index by staging some files.
-To create an index with a single entry – the first version of your test.txt file – you can use the plumbing command `update-index`.
-You use this command to artificially add the earlier version of the test.txt file to a new staging area.
+To create an index with a single entry – the first version of your `test.txt` file – you can use the plumbing command `update-index`.
+You use this command to artificially add the earlier version of the `test.txt` file to a new staging area.
 You must pass it the `--add` option because the file doesn't yet exist in your staging area (you don't even have a staging area set up yet) and `--cacheinfo` because the file you're adding isn't in your directory but is in your database.
 Then, you specify the mode, SHA-1, and filename:
 
@@ -183,7 +183,7 @@ $ git cat-file -t d8329fc1cc938780ffdd9f94e0d364e0ea74f579
 tree
 ----
 
-You'll now create a new tree with the second version of test.txt and a new file as well:
+You'll now create a new tree with the second version of `test.txt` and a new file as well:
 
 [source,console]
 ----
@@ -192,7 +192,7 @@ $ git update-index test.txt
 $ git update-index --add new.txt
 ----
 
-Your staging area now has the new version of test.txt as well as the new file new.txt.
+Your staging area now has the new version of `test.txt` as well as the new file `new.txt`.
 Write out that tree (recording the state of the staging area or index to a tree object) and see what it looks like:
 
 [source,console]
@@ -204,7 +204,7 @@ $ git cat-file -p 0155eb4229851634a0f03eb265b69f5a2d56f341
 100644 blob 1f7a7a472abf3dd9643fd615f6da379c4acb3e3a      test.txt
 ----
 
-Notice that this tree has both file entries and also that the test.txt SHA-1 is the ``version 2'' SHA-1 from earlier (`1f7a7a`).
+Notice that this tree has both file entries and also that the `test.txt` SHA-1 is the ``version 2'' SHA-1 from earlier (`1f7a7a`).
 Just for fun, you'll add the first tree as a subdirectory into this one.
 You can read trees into your staging area by calling `read-tree`.
 In this case, you can read an existing tree into your staging area as a subtree by using the `--prefix` option to `read-tree`:
@@ -220,7 +220,7 @@ $ git cat-file -p 3c4e9cd789d88d8d89c1073707c3585e41b0e614
 100644 blob 1f7a7a472abf3dd9643fd615f6da379c4acb3e3a      test.txt
 ----
 
-If you created a working directory from the new tree you just wrote, you would get the two files in the top level of the working directory and a subdirectory named `bak` that contained the first version of the test.txt file.
+If you created a working directory from the new tree you just wrote, you would get the two files in the top level of the working directory and a subdirectory named `bak` that contained the first version of the `test.txt` file.
 You can think of the data that Git contains for these structures as being like this:
 
 .The content structure of your current Git data.