switch all instances of 'git ...' to @git ...@ for consistent formatting

text/s1-c00-understanding-git.textile

@@ -4,7 +4,7 @@ In this section, we will go over what Git was built for and how it works, hopefu
 
 note.  The first commit message for the Git project was 'initial version of "git", the information manager from hell' - Linus, 4/7/05
 
-When I learned Git, as many people do, I learned it in the context of other SCMs I had used - Subversion or CVS.  I have come to believe that this is a horrible way to learn Git.  I felt far more comfortable with it when I stopped thinking that 'git add' was sort of like 'svn add', but instead understood what it was actually doing.  Then I found I could find new and interesting ways to use what is really a very powerful and cool toolset.
+When I learned Git, as many people do, I learned it in the context of other SCMs I had used - Subversion or CVS.  I have come to believe that this is a horrible way to learn Git.  I felt far more comfortable with it when I stopped thinking that @git add@ was sort of like 'svn add', but instead understood what it was actually doing.  Then I found I could find new and interesting ways to use what is really a very powerful and cool toolset.
 
 !vector/what-git-is.eps!
 

text/s2-c06-git-diff.textile

@@ -6,13 +6,13 @@ Two common uses of this include seeing what you've worked on but not committed y
 
 h3. What has changed?
 
-If you simply run 'git diff' with no arguments, it will show you the differences between your current working directory and your index, that is, the last time you ran 'git add' on your files. 
+If you simply run @git diff@ with no arguments, it will show you the differences between your current working directory and your index, that is, the last time you ran @git add@ on your files. 
 
 For example, if I add my email to the README file and run it, I will see this:
 
 shell. git-diff-readme.txt
 
-You can also use 'git diff' to show you some spiffy stats for a diff, rather than a patch file, if you want to see a wider overview of what changed, then drill down into specific files later.  Here are some examples getting stats, the first for the differences between two commits and the second a summary between a commit and the current HEAD.
+You can also use @git diff@ to show you some spiffy stats for a diff, rather than a patch file, if you want to see a wider overview of what changed, then drill down into specific files later.  Here are some examples getting stats, the first for the differences between two commits and the second a summary between a commit and the current HEAD.
 
 shell. git-diff-stat.txt
 
@@ -24,7 +24,7 @@ You can use this command to detect changes between your index and any tree, or y
 
 h3. Generating Patch Files
 
-The default output of the 'git diff' command is a valid patch file.  If you pipe the output into a file and email it to someone, they can apply it with the 'patch' command.  If you've done some work off of a project in an 'experiment' branch, you could create a patch file this way:
+The default output of the @git diff@ command is a valid patch file.  If you pipe the output into a file and email it to someone, they can apply it with the 'patch' command.  If you've done some work off of a project in an 'experiment' branch, you could create a patch file this way:
 
 shell. $ git diff master..experiment > experiment.patch
 

text/s2-c07-branching.textile

@@ -12,7 +12,7 @@ The other way is to checkout a branch that doesn't exist yet and tell git you wa
 
 shell. $ git checkout -b newfunc
 
-Now, to check which branch we are on, we just type 'git branch':
+Now, to check which branch we are on, we just type @git branch@:
 
 shell. git-branch.txt
 

text/s2-c09-rebasing.textile

@@ -10,19 +10,19 @@ If we do a simple merge, our history will look like this:
 
 !bitmap/repo.png!
 
-But we don't want to mess up our history with a bunch of branches and merges when it can be clearer.  Instead of running 'git merge story84' from the master branch, we can stay in the 'story84' branch and run 'git rebase master'
+But we don't want to mess up our history with a bunch of branches and merges when it can be clearer.  Instead of running @git merge story84@ from the master branch, we can stay in the 'story84' branch and run @git rebase master@
 
 shell. rebase-conflict.txt
 
 Many times this goes very smoothly and you can see all the new commits and trees written in place of the old ones.  In this case, I had edited the 'lib/simplegit.rb' file differently in each branch which caused a conflict.  I will have to resolve this conflict before I can continue the rebase.
 
 This gives us some options, since the rebase can do this at any point - say you have 8 commits to move onto the new branch - each one could cause a conflict and you will have to resolve them each manually.  The 'rebase' command will stop at each patch if it needs to and let you do this.  
 
-You have three things you can do here, you can either fix the file, run a 'git add' on it and then run a 'git rebase --continue', which will move on to the next patch until it's done.  Our second option is to run 'git rebase --abort', which will reset us to what our repo looked like before we tried the rebase. Or, we can run 'git rebase --skip', which will leave this one patch out, abandoning the change forever.
+You have three things you can do here, you can either fix the file, run a @git add@ on it and then run a @git rebase --continue@, which will move on to the next patch until it's done.  Our second option is to run @git rebase --abort@, which will reset us to what our repo looked like before we tried the rebase. Or, we can run @git rebase --skip@, which will leave this one patch out, abandoning the change forever.
 
-note.  Git rebase options for a conflict : *--continue* : tries to keep going once you've resolved it, *--abort* : gives up altogether and returns to the state before the rebase, *--skip* : skips this patch, abandoning it forever
+note.  Git rebase options for a conflict : @--continue@ : tries to keep going once you've resolved it, @--abort@ : gives up altogether and returns to the state before the rebase, @--skip@ : skips this patch, abandoning it forever
 
-In this case we will simply fix the conflict, run 'git add' on the file and then run 'git rebase --continue' which then makes our history look like this:
+In this case we will simply fix the conflict, run @git add@ on the file and then run @git rebase --continue@ which then makes our history look like this:
 
 !bitmap/repo3.png!
 
@@ -33,13 +33,13 @@ Then all we have to do is switch to the master branch and merge in 'story84' (wh
 
 h3. Interactive Rebasing
 
-Much like Git provides a nicer way to work with your index before committing with 'git add --interactive', there is an interactive rebasing option that can only be fairly described as the "bee's knees".
+Much like Git provides a nicer way to work with your index before committing with @git add --interactive@, there is an interactive rebasing option that can only be fairly described as the "bee's knees".
 
-Assume we have started working on a story to add the 'git add' functionality to our library and so we've started a new branch called 'story92' and done the work there.  Then we decide that the 'ls-tree' function needs to be recursive and make that change, then we tweak the library again, committing each time. Meanwhile we've pulled in a change that implements the same 'ls-tree' change differently into our 'master' branch.  
+Assume we have started working on a story to add the @git add@ functionality to our library and so we've started a new branch called 'story92' and done the work there.  Then we decide that the 'ls-tree' function needs to be recursive and make that change, then we tweak the library again, committing each time. Meanwhile we've pulled in a change that implements the same 'ls-tree' change differently into our 'master' branch.  
 
 !bitmap/repo-rebasei1.png!
 
-We can see before we try the merge that the same change is in each branch, and I can see that the master branch version is better, so I don't even really want to merge it, I just want to throw my change away.  Also, I don't really need the other two commits to be two commits, because the second one is just a tweak and should be included in the first one.  Lets use 'git rebase -i' to rebase this branch and make those changes.  When we run the command, our editor comes up, showing this:
+We can see before we try the merge that the same change is in each branch, and I can see that the master branch version is better, so I don't even really want to merge it, I just want to throw my change away.  Also, I don't really need the other two commits to be two commits, because the second one is just a tweak and should be included in the first one.  Lets use @git rebase -i@ to rebase this branch and make those changes.  When we run the command, our editor comes up, showing this:
 
 code. repo-rebase.txt
 

text/s2-c09a-stashing.textile

@@ -1,29 +1,29 @@
 h2. Stashing
 
-Stashing is a pretty simple concept that is incredibly useful and very easy to use.  If you are working on your code and you need to switch to another branch for some reason and don't want to commit your current state because it is only partially completed, you can run 'git stash', which will basically take the changes from your last commit to the current state of your working directory and store it temporarily.
+Stashing is a pretty simple concept that is incredibly useful and very easy to use.  If you are working on your code and you need to switch to another branch for some reason and don't want to commit your current state because it is only partially completed, you can run @git stash@, which will basically take the changes from your last commit to the current state of your working directory and store it temporarily.
 
 In the following example, I have a change to my 'lib/simplegit.rb' file, but it's not complete.
 
 shell. stash.txt
 
-Now I can see that my working directory is clean, as if I had committed, but I did not.  Now I can switch branches, work for a while somewhere else, then switch back. So where did that change go?  How do I get it back?  Well, I can see my stashes by running 'git stash list'.
+Now I can see that my working directory is clean, as if I had committed, but I did not.  Now I can switch branches, work for a while somewhere else, then switch back. So where did that change go?  How do I get it back?  Well, I can see my stashes by running @git stash list@.
 
 shell. stash-list.txt
 
-I see I have two stashes on the 'master' branch, both saved off of working from the same commit, and I have one stashed change off the 'experiment' branch.  However, I can't remember which stash was the one I want, so I can use 'git stash show' to figure it out.
+I see I have two stashes on the 'master' branch, both saved off of working from the same commit, and I have one stashed change off the 'experiment' branch.  However, I can't remember which stash was the one I want, so I can use @git stash show@ to figure it out.
 
 shell. stash-show.txt
 
-I can also use any normal git tools that will take a tree on it, for instance, 'git diff':
+I can also use any normal git tools that will take a tree on it, for instance, @git diff@:
 
 shell. stash-diff.txt
 
 And finally, I can apply it:
 
 shell. stash-apply.txt
 
-Now we can see that our working directory is back to where it was, with one file in an unstaged state.  Now I would have to 'git add' and 'git commit' it if I wanted to keep the change. 
+Now we can see that our working directory is back to where it was, with one file in an unstaged state.  Now I would have to @git add@ and @git commit@ it if I wanted to keep the change. 
 
-Normally it's not even this complicated.  If you run 'git stash apply' without the actual stash reference, it will just apply the last stash you saved on that branch.  Normally I will just use 'git stash' to save something, go work elsewhere, then come back and run 'git stash apply' to get back to where I was.
+Normally it's not even this complicated.  If you run @git stash apply@ without the actual stash reference, it will just apply the last stash you saved on that branch.  Normally I will just use @git stash@ to save something, go work elsewhere, then come back and run @git stash apply@ to get back to where I was.
 
 * "git stash":http://www.kernel.org/pub/software/scm/git/docs/git-stash.html

text/s2-c10b-care-and-feeding.textile

@@ -4,7 +4,7 @@ Git requires a bit of tender loving care from time to time.  It may seem a bit o
 
 h3. garbage collection
 
-The 'git gc' command is an important one to remember.  It will pack up your objects into the delta-compressed format, saving you a lot of space and seriously speeding up several commands.
+The @git gc@ command is an important one to remember.  It will pack up your objects into the delta-compressed format, saving you a lot of space and seriously speeding up several commands.
 
 shell. git-gc.txt
 

text/s2-c11-distributed-workflow.textile

@@ -10,7 +10,7 @@ If you want to begin working on an existing project, you will need to get an ini
 
 When you clone a repository, it in essence copies all the git objects to a new directory, checks you out a single local branch named the same as the HEAD branch on the cloned repo (normally 'master'), and stores all the other branches under a remote reference by default named 'origin'.
 
-That means that if we cloned the repo in the previous examples, instead of 'story84' being a local branch you can switch to, it becomes 'origin/story84' that you have to create a local branch to pull into in order to work on (eg: 'git checkout --track story84 origin/story84')  
+That means that if we cloned the repo in the previous examples, instead of 'story84' being a local branch you can switch to, it becomes 'origin/story84' that you have to create a local branch to pull into in order to work on (eg: @git checkout --track story84 origin/story84@)  
 The '--track' indicates that you may want to pull from or push to the origin of this branch later, so remember where it came from.
 
 h4. Local Clones
@@ -46,7 +46,7 @@ This will contact the server over the same protocol we used to clone it and grab
 
 So, if we did create a tracking branch on 'story84' and it was changed on the server (someone pushed an update), before we fetch, our local 'story84' branch and our remote 'origin/story84' branch will be the same.  After we fetch, they will be different.  'origin/story84' will now point to one of the new commit objects we downloaded during the fetch.  
 
-At this point, we may want to merge 'origin/story84' into our local 'story84' branch.  That's easy enough, but if we want to do it automatically every time we fetch, we can use 'git pull', which is just a 'fetch' and then a 'merge' command.  
+At this point, we may want to merge 'origin/story84' into our local 'story84' branch.  That's easy enough, but if we want to do it automatically every time we fetch, we can use @git pull@, which is just a 'fetch' and then a 'merge' command.  
 
 So, these commands are functionally equivalent:
 

text/s3-c00-commands-overview.textile

@@ -26,15 +26,15 @@ Removes files from your index and your working directory so they will stopped be
 
 h3. "git commit":http://www.kernel.org/pub/software/scm/git/docs/git-commit.html 
 
-Takes all of the changes staged in the index (that have been 'git add'ed),  creates a new commit object pointing to it, and advances the branch to point to that new commit.
+Takes all of the changes staged in the index (that have been @git add@ed),  creates a new commit object pointing to it, and advances the branch to point to that new commit.
 
 h3. "git status":http://www.kernel.org/pub/software/scm/git/docs/git-status.html
 
 Shows you the status of files in your index versus your working directory.  It will list out files that are untracked (only in your working directory), modified (tracked but not yet updated in your index), and staged (added to your index and ready for committing).
 
 h3. "git branch":http://www.kernel.org/pub/software/scm/git/docs/git-branch.html
 
-Lists existing branches, including remote branches if '-a' is provided.  Creates a new branch if a branch name is provided.  Branches can also be created with '-b' option to 'git checkout'.
+Lists existing branches, including remote branches if '-a' is provided.  Creates a new branch if a branch name is provided.  Branches can also be created with '-b' option to @git checkout@.
 
 h3. "git checkout":http://www.kernel.org/pub/software/scm/git/docs/git-checkout.html
 
@@ -66,7 +66,7 @@ Fetches all the objects that a remote version of your repository has that you do
 
 h3. "git pull":http://www.kernel.org/pub/software/scm/git/docs/git-pull.html
 
-Runs a 'git fetch' then a 'git merge'.
+Runs a @git fetch@ then a @git merge@.
 
 h3. "git push":http://www.kernel.org/pub/software/scm/git/docs/git-push.html