[Fix] add missing colon

Vipul Kumar · Vipul Kumar · commit 7d59c28a0b1a · 2020-07-03T15:55:35.000Z
We generally separate statement and commands with a colon.
diff --git a/book/01-introduction/sections/help.asc b/book/01-introduction/sections/help.asc
@@ -10,7 +10,7 @@ $ git <verb> --help
 $ man git-<verb>
 ----
 
-For example, you can get the manpage help for the `git config` command by running(((git commands, help)))
+For example, you can get the manpage help for the `git config` command by running:(((git commands, help)))
 
 [source,console]
 ----
diff --git a/book/01-introduction/sections/installing.asc b/book/01-introduction/sections/installing.asc
@@ -114,7 +114,7 @@ If you're using a RPM-based distribution (Fedora/RHEL/RHEL-derivatives), you als
 $ sudo dnf install getopt
 ----
 
-Additionally, if you're using Fedora/RHEL/RHEL-derivatives, you need to do this
+Additionally, if you're using Fedora/RHEL/RHEL-derivatives, you need to do this:
 
 [source,console]
 ----
diff --git a/book/02-git-basics/sections/viewing-history.asc b/book/02-git-basics/sections/viewing-history.asc
@@ -5,7 +5,7 @@ After you have created several commits, or if you have cloned a repository with
 The most basic and powerful tool to do this is the `git log` command.
 
 These examples use a very simple project called ``simplegit''.
-To get the project, run
+To get the project, run:
 
 [source,console]
 ----
diff --git a/book/04-git-server/sections/git-on-a-server.asc b/book/04-git-server/sections/git-on-a-server.asc
@@ -23,7 +23,7 @@ done.
 
 You should now have a copy of the Git directory data in your `my_project.git` directory.
 
-This is roughly equivalent to something like
+This is roughly equivalent to something like:
 
 [source,console]
 ----
@@ -45,7 +45,7 @@ Assuming that `/srv/git` exists on that server, you can set up your new reposito
 $ scp -r my_project.git user@git.example.com:/srv/git
 ----
 
-At this point, other users who have SSH-based read access to the `/srv/git` directory on that server can clone your repository by running
+At this point, other users who have SSH-based read access to the `/srv/git` directory on that server can clone your repository by running:
 
 [source,console]
 ----
diff --git a/book/04-git-server/sections/protocols.asc b/book/04-git-server/sections/protocols.asc
@@ -105,7 +105,7 @@ $ chmod a+x hooks/post-update
 
 That's all.(((hooks, post-update)))
 The `post-update` hook that comes with Git by default runs the appropriate command (`git update-server-info`) to make HTTP fetching and cloning work properly.
-This command is run when you push to this repository (over SSH perhaps); then, other people can clone via something like
+This command is run when you push to this repository (over SSH perhaps); then, other people can clone via something like:
 
 [source,console]
 ----
diff --git a/book/05-distributed-git/sections/maintaining.asc b/book/05-distributed-git/sections/maintaining.asc
@@ -384,7 +384,7 @@ For example, suppose you have a project that looks like this:
 .Example history before a cherry-pick
 image::images/rebasing-1.png[Example history before a cherry-pick]
 
-If you want to pull commit `e43a6` into your `master` branch, you can run
+If you want to pull commit `e43a6` into your `master` branch, you can run:
 
 [source,console]
 ----
diff --git a/book/07-git-tools/sections/advanced-merging.asc b/book/07-git-tools/sections/advanced-merging.asc
@@ -226,7 +226,7 @@ In the `ignore-space-change` merge, we actually ended up with a few lines with D
 If you want to get an idea before finalizing this commit about what was actually changed between one side or the other, you can ask `git diff` to compare what is in your working directory that you're about to commit as the result of the merge to any of these stages.
 Let's go through them all.
 
-To compare your result to what you had in your branch before the merge, in other words, to see what the merge introduced, you can run `git diff --ours`
+To compare your result to what you had in your branch before the merge, in other words, to see what the merge introduced, you can run `git diff --ours`:
 
 [source,console]
 ----
diff --git a/book/07-git-tools/sections/revision-selection.asc b/book/07-git-tools/sections/revision-selection.asc
@@ -138,7 +138,7 @@ $ git show HEAD@{5}
 ----
 
 You can also use this syntax to see where a branch was some specific amount of time ago.
-For instance, to see where your `master` branch was yesterday, you can type
+For instance, to see where your `master` branch was yesterday, you can type:
 
 [source,console]
 ----
@@ -252,7 +252,7 @@ The other main ancestry specification is the `~` (tilde).
 This also refers to the first parent, so `HEAD~` and `HEAD^` are equivalent.
 The difference becomes apparent when you specify a number.
 `HEAD~2` means ``the first parent of the first parent,'' or ``the grandparent'' -- it traverses the first parents the number of times you specify.
-For example, in the history listed earlier, `HEAD~3` would be
+For example, in the history listed earlier, `HEAD~3` would be:
 
 [source,console]
 ----
diff --git a/book/07-git-tools/sections/rewriting-history.asc b/book/07-git-tools/sections/rewriting-history.asc
@@ -150,15 +150,15 @@ Once you're satisfied with your changes, run
 ----
 
 These instructions tell you exactly what to do.
-Type
+Type:
 
 [source,console]
 ----
 $ git commit --amend
 ----
 
 Change the commit message, and exit the editor.
-Then, run
+Then, run:
 
 [source,console]
 ----
@@ -172,7 +172,7 @@ Each time, Git will stop, let you amend the commit, and continue when you're fin
 ==== Reordering Commits
 
 You can also use interactive rebases to reorder or remove commits entirely.
-If you want to remove the ``added cat-file'' commit and change the order in which the other two commits are introduced, you can change the rebase script from this
+If you want to remove the ``added cat-file'' commit and change the order in which the other two commits are introduced, you can change the rebase script from this:
 
 [source,console]
 ----
diff --git a/book/07-git-tools/sections/subtree-merges.asc b/book/07-git-tools/sections/subtree-merges.asc
@@ -95,7 +95,7 @@ Instead, you must run `git diff-tree` with the branch you want to compare to:
 $ git diff-tree -p rack_branch
 ----
 
-Or, to compare what is in your `rack` subdirectory with what the `master` branch on the server was the last time you fetched, you can run
+Or, to compare what is in your `rack` subdirectory with what the `master` branch on the server was the last time you fetched, you can run:
 
 [source,console]
 ----
diff --git a/book/08-customizing-git/sections/config.asc b/book/08-customizing-git/sections/config.asc
@@ -37,7 +37,7 @@ It's generally easier to run the `git config` command, though.
 The configuration options recognized by Git fall into two categories: client-side and server-side.
 The majority of the options are client-side -- configuring your personal working preferences.
 Many, _many_ configuration options are supported, but a large fraction of them are useful only in certain edge cases; we'll cover just the most common and useful options here.
-If you want to see a list of all the options your version of Git recognizes, you can run
+If you want to see a list of all the options your version of Git recognizes, you can run:
 
 [source,console]
 ----
@@ -227,7 +227,7 @@ Each of these can be set to `true`, `false`, or `always`:
   color.status
 
 In addition, each of these has subsettings you can use to set specific colors for parts of the output, if you want to override each color.
-For example, to set the meta information in your diff output to blue foreground, black background, and bold text, you can run
+For example, to set the meta information in your diff output to blue foreground, black background, and bold text, you can run:
 
 [source,console]
 ----
@@ -287,7 +287,7 @@ $ sudo chmod +x /usr/local/bin/extDiff
 
 Now you can set up your config file to use your custom merge resolution and diff tools.
 This takes a number of custom settings: `merge.tool` to tell Git what strategy to use, `mergetool.<tool>.cmd` to specify how to run the command, `mergetool.<tool>.trustExitCode` to tell Git if the exit code of that program indicates a successful merge resolution or not, and `diff.external` to tell Git what command to run for diffs.
-So, you can either run four config commands
+So, you can either run four config commands:
 
 [source,console]
 ----
@@ -369,7 +369,7 @@ Some of the tools listed above only work in a windowed
 environment. If run in a terminal-only session, they will fail.
 ----
 
-If you're not interested in using KDiff3 for diff but rather want to use it just for merge resolution, and the kdiff3 command is in your path, then you can run
+If you're not interested in using KDiff3 for diff but rather want to use it just for merge resolution, and the kdiff3 command is in your path, then you can run:
 
 [source,console]
 ----
diff --git a/book/08-customizing-git/sections/policy.asc b/book/08-customizing-git/sections/policy.asc
@@ -270,7 +270,7 @@ error: failed to push some refs to 'git@gitserver:project.git'
 You'll see a remote rejected message for each reference that your hook declined, and it tells you that it was declined specifically because of a hook failure.
 
 Furthermore, if someone tries to edit a file they don't have access to and push a commit containing it, they will see something similar.
-For instance, if a documentation author tries to push a commit modifying something in the `lib` directory, they see
+For instance, if a documentation author tries to push a commit modifying something in the `lib` directory, they see:
 
 [source,console]
 ----
@@ -360,7 +360,7 @@ check_directory_perms
 
 This is roughly the same script as the server-side part, but with two important differences.
 First, the ACL file is in a different place, because this script runs from your working directory, not from your `.git` directory.
-You have to change the path to the ACL file from this
+You have to change the path to the ACL file from this:
 
 [source,ruby]
 ----
@@ -376,14 +376,14 @@ access = get_acl_access_data('.git/acl')
 
 The other important difference is the way you get a listing of the files that have been changed.
 Because the server-side method looks at the log of commits, and, at this point, the commit hasn't been recorded yet, you must get your file listing from the staging area instead.
-Instead of
+Instead of:
 
 [source,ruby]
 ----
 files_modified = `git log -1 --name-only --pretty=format:'' #{ref}`
 ----
 
-you have to use
+you have to use:
 
 [source,ruby]
 ----
diff --git a/book/09-git-and-other-scms/sections/client-svn.asc b/book/09-git-and-other-scms/sections/client-svn.asc
@@ -58,7 +58,7 @@ $ svnsync init file:///tmp/test-svn \
 ----
 
 This sets up the properties to run the sync.
-You can then clone the code by running
+You can then clone the code by running:
 
 [source,console]
 ----
@@ -362,7 +362,7 @@ It's important to note that it doesn't check you out into that branch; if you co
 Git figures out what branch your dcommits go to by looking for the tip of any of your Subversion branches in your history – you should have only one, and it should be the last one with a `git-svn-id` in your current branch history.
 
 If you want to work on more than one branch simultaneously, you can set up local branches to `dcommit` to specific Subversion branches by starting them at the imported Subversion commit for that branch.
-If you want an `opera` branch that you can work on separately, you can run
+If you want an `opera` branch that you can work on separately, you can run:
 
 [source,console]
 ----
diff --git a/book/09-git-and-other-scms/sections/import-svn.asc b/book/09-git-and-other-scms/sections/import-svn.asc
@@ -57,7 +57,7 @@ $ cd my_project
 ----
 
 Now you should have a nicer Subversion import in your `my_project` directory.
-Instead of commits that look like this
+Instead of commits that look like this:
 
 [source]
 ----
diff --git a/book/10-git-internals/sections/refspec.asc b/book/10-git-internals/sections/refspec.asc
@@ -101,7 +101,7 @@ If you have a complex workflow process that has a QA team pushing branches, deve
 It's nice that you can fetch namespaced references that way, but how does the QA team get their branches into a `qa/` namespace in the first place?
 You accomplish that by using refspecs to push.
 
-If the QA team wants to push their `master` branch to `qa/master` on the remote server, they can run
+If the QA team wants to push their `master` branch to `qa/master` on the remote server, they can run:
 
 [source,console]
 ----
