add git to the subsections

progit · ben · Oct 21, 2014 · Oct 8, 2014 · Oct 9, 2014 · Oct 9, 2014
commit 57eb252076c5dcd781d22d040289a16e1b095b10
diff --git a/book/C-git-commands/1-git-commands.asc b/book/C-git-commands/1-git-commands.asc
@@ -243,7 +243,7 @@ We also cover how to create a GPG signed tag with the `-s` flag and verify one w
 
 There are not very many commands in Git that access the network, nearly all of the commands operate on the local database. When you are ready to share your work or pull changes from elsewhere, there are a handful of commands that deal with remote repositories.
 
-==== fetch
+==== git fetch
 
 The `git fetch` command communicates with a remote repository and fetches down all the information that is in that repository that is not in your current one and stores it in your local database.
 
@@ -255,7 +255,7 @@ We use it to fetch a single specific reference that is outside of the default sp
 
 We set up highly custom refspecs in order to make `git fetch` do something a little different than the default in <<_getting_notes>> and <<_refspec>>.
 
-==== pull
+==== git pull
 
 The `git pull` command is basically a combination of the `git fetch` and `git merge` commands, where Git will fetch from the remote you specify and then immediately try to merge it into the branch you're on.
 
@@ -267,7 +267,7 @@ We show how to use it with a URL to pull in changes in a one-off fashion in <<_c
 
 Finally, we very quickly mention that you can use the `--verify-signatures` option to it in order to verify that commits you are pulling have been GPG signed in <<_signing_commits>>.
 
-==== push
+==== git push
 
 The `git push` command is used to communicate with another repository, calculate what your local database has that the remote one does not, and then pushes the difference into the other repository. It requires write access to the other repository and so normally is authenticated somehow.
 
@@ -285,29 +285,29 @@ In <<_other_client_hooks>> we talk briefly about the `pre-push` hook, which is a
 
 Finally, in <<_pushing_refspecs>> we look at pushing with a full refspec instead of the general shortcuts that are normally used. This can help you be very specific about what work you wish to share.
 
-==== remote
+==== git remote
 
 The `git remote` command is a management tool for your record of remote repositories. It allows you to save long URLs as short handles, such as ``origin'' so you don't have to type them out all the time. You can have several of these and the `git remote` command is used to add, change and delete them.
 
 This command is covered in detail in <<_remote_repos>>, including listing, adding, removing and renaming them.
 
 It is used in nearly every subsequent chapter in the book too, but always in the standard `git remote add <name> <url>` format.
 
-==== archive
+==== git archive
 
 The `git archive` command is used to create an archive file of a specific snapshot of the project.
 
 We use `git archive` to create a tarball of a project for sharing in <<_preparing_release>>.
 
-==== submodule
+==== git submodule
 
 The `git submodule` command is used to manage external repositories within a normal repositories. This could be for libraries or other types of shared resources. The `submodule` command has several sub-commands (`add`, `update`, `sync`, etc) for managing these resources.
 
 This command is only mentioned and entirely covered in <<_git_submodules>>.
 
 === Inspection and Comparison
 
-==== show
+==== git show
 
 The `git show` command can show a Git object in a simple and human readable way. Normally you would use this to show the information about a tag or a commit.
 
@@ -317,13 +317,13 @@ Later we use it quite a bit in <<_revision_selection>> to show the commits that
 
 One of the more interesting things we do with `git show` is in <<_manual_remerge>> to extract specific file contents of various stages during a merge conflict.
 
-==== shortlog
+==== git shortlog
 
 The `git shortlog` command is used to summarize the output of `git log`. It will take many of the same options that the `git log` command will but instead of listing out all of the commits it will present a summary of the commits grouped by author.
 
 We showed how to use it to create a nice changelog in <<_the_shortlog>>.
 
-==== describe
+==== git describe
 
 The `git describe` command is used to take anything that resolves to a commit and produces a string that is somewhat human-readable and will not change. It's a way to get a description of a commit that is as unambiguous as a commit SHA but more understandable.
 
@@ -334,19 +334,19 @@ We use `git describe` in <<_build_number>> and <<_preparing_release>> to get a s
 
 Git has a couple of commands that are used to help debug an issue in your code. This ranges from figuring out where something was introduced to figuring out who introduced it.
 
-==== bisect
+==== git bisect
 
 The `git bisect` tool is an incredibly helpful debugging tool used to find which specific commit was the first one to introduce a bug or problem by doing an automatic binary search.
 
 It is fully covered in <<_binary_search>> and is only mentioned in that section.
 
-==== blame
+==== git blame
 
 The `git blame` command annotates the lines of any file with which commit was the last one to introduce a change to each line of the file and what person authored that commit. This is helpful in order to find the person to ask for more information about a specific section of your code.
 
 It is covered in <<_file_annotation>> and is only mentioned in that section.
 
-==== grep
+==== git grep
 
 The `git grep` command can help you find any string or regular expression in any of the files in your source code, even older versions of your project.
 
@@ -356,13 +356,13 @@ It is covered in <<_git_grep>> and is only mentioned in that section.
 
 A few commands in Git are centered around the concept of thinking of commits in terms of the changes they introduce, as thought the commit series is a series of patches. These commands help you manage your branches in this manner.
 
-==== cherry-pick
+==== git cherry-pick
 
 The `git cherry-pick` command is used to take the change introduced in a single Git commit and try to re-introduce it as a new commit on the branch you're currently on. This can be useful to only take one or two commits from a branch individually rather than merging in the branch which takes all the changes.
 
 Cherry picking is described and demonstrated in <<_rebase_cherry_pick>>.
 
-==== rebase
+==== git rebase
 
 The `git rebase` command is basically an automated `cherry-pick`. It determines a series of commits and then cherry-picks them one by one in the same order somewhere else.
 
@@ -374,7 +374,7 @@ We go through running into a merge conflict during rebasing in <<_rerere>>.
 
 We also use it in an interactive scripting mode with the `-i` option in <<_changing_multiple>>.
 
-==== revert
+==== git revert
 
 The `git revert` command is essentially a reverse `git cherry-pick`. It creates a new commit that applies the exact opposite of the change introduced in the commit you're targeting, essentially undoing or reverting it.
 
@@ -384,13 +384,13 @@ We use this in <<_reverse_commit>> to undo a merge commit.
 
 Many Git projects, including Git itself, are entirely maintained over mailing lists. Git has a number of tools built into it that help make this process easier, from generating patches you can easily email to applying those patches from an email box.
 
-==== apply
+==== git apply
 
 The `git apply` command applies a patch created with the `git diff` or even GNU diff command. It is similar to what the `patch` command might do with a few small differences.
 
 We demonstrate using it and the circumstances in which you might do so in <<_patches_from_email>>.
 
-==== am
+==== git am
 
 The `git am` command is used to apply patches from an email inbox, specifically one that is mbox formatted. This is useful for receiving patches over email and applying them to your project easily.
 
@@ -400,19 +400,19 @@ There are also a number of hooks you can use to help with the workflow around `g
 
 We also use it to apply patch formatted GitHub Pull Request changes in <<_email_notifications>>.
 
-==== format-patch
+==== git format-patch
 
 The `git format-patch` command is used to generate a series of patches in mbox format that you can use to send to a mailing list properly formatted.
 
 We go through an example of contributing to a project using the `git format-patch` tool in <<_project_over_email>>.
 
-==== send-email
+==== git send-email
 
 The `git send-email` command is used to send patches that are generated with `git format-patch` over email.
 
 We go through an example of contributing to a project by sending patches with the `git send-email` tool in <<_project_over_email>>.
 
-==== request-pull
+==== git request-pull
 
 The `git request-pull` command is simply used to generate an example message body to email to someone. If you have a branch on a public server and want to let someone know how to integrate those changes without sending the patches over email, you can run this command and send the output to the person you want to pull the changes in.
 
@@ -422,13 +422,13 @@ We demonstrate how to use `git request-pull` to generate a pull message in <<_pu
 
 Git comes with a few commands to integrate with other version control systems.
 
-==== svn
+==== git svn
 
 The `git svn` command is used to communicate with the Subversion version control system as a client. This means you can use Git to checkout from and commit to a Subversion server.
 
 This command is covered in depth in <<_git_svn>>.
 
-==== fast-import
+==== git fast-import
 
 For other version control systems or importing from nearly any format, you can use `git fast-import` to quickly map the other format to something Git can easily record.
 
@@ -438,27 +438,27 @@ This command is coverd in depth in <<_custom_importer>>.
 
 If you're administering a Git repository or need to fix something in a big way, Git provides a number of administrative commands to help you out.
 
-==== gc
+==== git gc
 
 The `git gc` command runs ``garbage collection'' on your repository, removing unnecessary files in your database and packing up the remaining files into a more efficient format.
 
 This command normally runs in the background for you, though you can manually run it if you wish. We go over some examples of this in <<_git_gc>>.
 
-==== fsck
+==== git fsck
 
 The `git fsck` command is used to check the internal database for problems or inconsistencies.
 
 We only quickly use this once in <<_data_recovery>> to search for dangling objects.
 
-==== reflog
+==== git reflog
 
 The `git reflog` command goes through a log of where all the heads of your branches have been as you work to find commits you may have lost through rewriting histories.
 
 We cover this command mainly in <<_git_reflog>>, where we show normal usage to and how to use `git log -g` to view the same information with `git log` output.
 
 We also go through a practical example of recovering such a lost branch in <<_data_recovery>>.
 
-==== filter-branch
+==== git filter-branch
 
 The `git filter-branch` command is used to rewrite loads of commits according to certain patterns, like removing a file everywhere or filtering the entire repository down to a single subdirectory for extracting a project.