[Fix] remove period mark from the figure captions

If a paragraph ends with a figure caption, it ends with double period
marks. One of them is due to figure caption, which itself ends with a
period and other is for end of paragraph.

So removing period from figure captions would be a good idea, as Ben has
suggested[1].

Due to this commit, now some paragraphs don't have any period mark at
end of paragraph. Those period are their because of caption, that's
paragraphs itself don't end with any period, see [2].

[1]: #1437 (comment)
[2]: #1444 (comment)

Resolves: #1437

Author: Vipul Kumar

book/01-introduction/sections/about-version-control.asc

@@ -19,7 +19,7 @@ It is easy to forget which directory you're in and accidentally write to the wro
 
 To deal with this issue, programmers long ago developed local VCSs that had a simple database that kept all the changes to files under revision control.
 
-.Local version control.
+.Local version control
 image::images/local.png[Local version control diagram]
 
 One of the most popular VCS tools was a system called RCS, which is still distributed with many computers today.
@@ -33,7 +33,7 @@ To deal with this problem, Centralized Version Control Systems (CVCSs) were deve
 These systems (such as CVS, Subversion, and Perforce) have a single server that contains all the versioned files, and a number of clients that check out files from that central place. (((CVS)))(((Subversion)))(((Perforce)))
 For many years, this has been the standard for version control.
 
-.Centralized version control.
+.Centralized version control
 image::images/centralized.png[Centralized version control diagram]
 
 This setup offers many advantages, especially over local VCSs.
@@ -54,7 +54,7 @@ In a DVCS (such as Git, Mercurial, Bazaar or Darcs), clients don't just check ou
 Thus, if any server dies, and these systems were collaborating via that server, any of the client repositories can be copied back up to the server to restore it.
 Every clone is really a full backup of all the data.
 
-.Distributed version control.
+.Distributed version control
 image::images/distributed.png[Distributed version control diagram]
 
 Furthermore, many of these systems deal pretty well with having several remote repositories they can work with, so you can collaborate with different groups of people in different ways simultaneously within the same project.

book/01-introduction/sections/installing.asc

@@ -48,7 +48,7 @@ If you don't have it installed already, it will prompt you to install it.
 If you want a more up to date version, you can also install it via a binary installer.
 A macOS Git installer is maintained and available for download at the Git website, at https://git-scm.com/download/mac[].
 
-.Git macOS Installer.
+.Git macOS Installer
 image::images/git-osx-installer.png[Git macOS installer.]
 
 You can also install it as part of the GitHub for macOS install.

book/01-introduction/sections/what-is-git.asc

@@ -11,7 +11,7 @@ The major difference between Git and any other VCS (Subversion and friends inclu
 Conceptually, most other systems store information as a list of file-based changes.
 These other systems (CVS, Subversion, Perforce, Bazaar, and so on) think of the information they store as a set of files and the changes made to each file over time (this is commonly described as _delta-based_ version control).
 
-.Storing data as changes to a base version of each file.
+.Storing data as changes to a base version of each file
 image::images/deltas.png[Storing data as changes to a base version of each file.]
 
 Git doesn't think of or store its data this way.
@@ -20,7 +20,7 @@ With Git, every time you commit, or save the state of your project, Git basicall
 To be efficient, if files have not changed, Git doesn't store the file again, just a link to the previous identical file it has already stored.
 Git thinks about its data more like a *stream of snapshots*.
 
-.Storing data as snapshots of the project over time.
+.Storing data as snapshots of the project over time
 image::images/snapshots.png[Git stores data as snapshots of the project over time.]
 
 This is an important distinction between Git and nearly all other VCSs.
@@ -84,7 +84,7 @@ Git has three main states that your files can reside in: _modified_, _staged_, a
 
 This leads us to the three main sections of a Git project: the working tree, the staging area, and the Git directory.
 
-.Working tree, staging area, and Git directory.
+.Working tree, staging area, and Git directory
 image::images/areas.png["Working tree, staging area, and Git directory."]
 
 The working tree is a single checkout of one version of the project.

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

@@ -13,7 +13,7 @@ When you first clone a repository, all of your files will be tracked and unmodif
 As you edit files, Git sees them as modified, because you've changed them since your last commit.
 As you work, you selectively stage these modified files and then commit all those staged changes, and the cycle repeats.
 
-.The lifecycle of the status of your files.
+.The lifecycle of the status of your files
 image::images/lifecycle.png[The lifecycle of the status of your files.]
 
 [[_checking_status]]

book/03-git-branching/sections/rebasing.asc

@@ -198,7 +198,7 @@ For instance, in the previous scenario, if instead of doing a merge when we're a
 So instead of the result we see in <<_merge_rebase_work>>, we would end up with something more like <<_rebase_rebase_work>>.
 
 [[_rebase_rebase_work]]
-.Rebase on top of force-pushed rebase work.
+.Rebase on top of force-pushed rebase work
 image::images/perils-of-rebasing-5.png[Rebase on top of force-pushed rebase work.]
 
 This only works if `C4` and `C4'` that your partner made are almost exactly the same patch.

book/04-git-server/sections/gitlab.asc

@@ -16,7 +16,7 @@ To get something up and running quickly, you can download a virtual machine imag
 One nice touch Bitnami has included is the login screen (accessed by typing alt+→); it tells you the IP address and default username and password for the installed GitLab.
 
 [[bitnami]]
-.The Bitnami GitLab virtual machine login screen.
+.The Bitnami GitLab virtual machine login screen
 image::images/bitnami.png[The Bitnami GitLab virtual machine login screen.]
 
 For anything else, follow the guidance in the GitLab Community Edition readme, which can be found at https://gitlab.com/gitlab-org/gitlab-ce/tree/master[].
@@ -31,7 +31,7 @@ The default username is `[email protected]`, and the default password is `5iveL!f
 Once logged in, click the ``Admin area'' icon in the menu at the top right.
 
 [[gitlab_menu]]
-.The ``Admin area'' item in the GitLab menu.
+.The ``Admin area'' item in the GitLab menu
 image::images/gitlab-menu.png[The ``Admin area'' item in the GitLab menu.]
 
 ===== Users
@@ -42,7 +42,7 @@ Each user account comes with a *namespace*, which is a logical grouping of proje
 If the user +jane+ had a project named +project+, that project's url would be `http://server/jane/project`.
 
 [[gitlab_users]]
-.The GitLab user administration screen.
+.The GitLab user administration screen
 image::images/gitlab-users.png[The GitLab user administration screen.]
 
 Removing a user can be done in two ways.
@@ -59,7 +59,7 @@ A GitLab group is an assemblage of projects, along with data about how users can
 Each group has a project namespace (the same way that users do), so if the group +training+ has a project +materials+, its url would be `http://server/training/materials`.
 
 [[gitlab_groups]]
-.The GitLab group administration screen.
+.The GitLab group administration screen
 image::images/gitlab-groups.png[The GitLab group administration screen.]
 
 Each group is associated with a number of users, each of which has a level of permissions for the group's projects and the group itself.

book/04-git-server/sections/gitweb.asc

@@ -5,7 +5,7 @@ Now that you have basic read/write and read-only access to your project, you may
 Git comes with a CGI script called GitWeb that is sometimes used for this.
 
 [[gitweb]]
-.The GitWeb web-based user interface.
+.The GitWeb web-based user interface
 image::images/git-instaweb.png[The GitWeb web-based user interface.]
 
 If you want to check out what GitWeb would look like for your project, Git comes with a command to fire up a temporary instance if you have a lightweight web server on your system like `lighttpd` or `webrick`.

book/05-distributed-git/sections/contributing.asc

@@ -41,7 +41,7 @@ The Git project provides a document that lays out a number of good tips for crea
 First, your submissions should not contain any whitespace errors.
 Git provides an easy way to check for this -- before you commit, run `git diff --check`, which identifies possible whitespace errors and lists them for you.
 
-.Output of `git diff --check`.
+.Output of `git diff --check`
 image::images/git-diff-check.png[Output of `git diff --check`.]
 
 If you run that command before committing, you can tell if you're about to commit whitespace issues that may annoy other developers.
@@ -184,7 +184,7 @@ From john@githost:simplegit
 
 At this point, John's local repository looks something like this:
 
-.John's divergent history.
+.John's divergent history
 image::images/small-team-1.png[John's divergent history.]
 
 Now John can merge Jessica's work that he fetched into his own local work:
@@ -199,7 +199,7 @@ Merge made by the 'recursive' strategy.
 
 As long as that local merge goes smoothly, John's updated history will now look like this:
 
-.John's repository after merging `origin/master`.
+.John's repository after merging `origin/master`
 image::images/small-team-2.png[John's repository after merging `origin/master`.]
 
 At this point, John might want to test this new code to make sure none of Jessica's work affects any of his and, as long as everything seems fine, he can finally push the new merged work up to the server:
@@ -214,13 +214,13 @@ To john@githost:simplegit.git
 
 In the end, John's commit history will look like this:
 
-.John's history after pushing to the `origin` server.
+.John's history after pushing to the `origin` server
 image::images/small-team-3.png[John's history after pushing to the `origin` server.]
 
 In the meantime, Jessica has created a new topic branch called `issue54`, and made three commits to that branch.
 She hasn't fetched John's changes yet, so her commit history looks like this:
 
-.Jessica's topic branch.
+.Jessica's topic branch
 image::images/small-team-4.png[Jessica's topic branch.]
 
 Suddenly, Jessica learns that John has pushed some new work to the server and she wants to take a look at it, so she can fetch all new content from the server that she does not yet have with:
@@ -237,7 +237,7 @@ From jessica@githost:simplegit
 That pulls down the work John has pushed up in the meantime.
 Jessica's history now looks like this:
 
-.Jessica's history after fetching John's changes.
+.Jessica's history after fetching John's changes
 image::images/small-team-5.png[Jessica's history after fetching John's changes.]
 
 Jessica thinks her topic branch is ready, but she wants to know what part of John's fetched work she has to merge into her work so that she can push.
@@ -298,7 +298,7 @@ Merge made by the 'recursive' strategy.
 
 Everything merges cleanly, and Jessica's history now looks like this:
 
-.Jessica's history after merging John's changes.
+.Jessica's history after merging John's changes
 image::images/small-team-6.png[Jessica's history after merging John's changes.]
 
 Now `origin/master` is reachable from Jessica's `master` branch, so she should be able to successfully push (assuming John hasn't pushed even more changes in the meantime):
@@ -313,15 +313,15 @@ To jessica@githost:simplegit.git
 
 Each developer has committed a few times and merged each other's work successfully.
 
-.Jessica's history after pushing all changes back to the server.
+.Jessica's history after pushing all changes back to the server
 image::images/small-team-7.png[Jessica's history after pushing all changes back to the server.]
 
 That is one of the simplest workflows.
 You work for a while (generally in a topic branch), and merge that work into your `master` branch when it's ready to be integrated.
 When you want to share that work, you fetch and merge your `master` from `origin/master` if it has changed, and finally push to the `master` branch on the server.
 The general sequence is something like this:
 
-.General sequence of events for a simple multiple-developer Git workflow.
+.General sequence of events for a simple multiple-developer Git workflow
 image::images/small-team-flow.png[General sequence of events for a simple multiple-developer Git workflow.]
 
 ==== Private Managed Team
@@ -388,7 +388,7 @@ $ git commit -am 'Add ls-files'
 
 Jessica's repository now looks like this:
 
-.Jessica's initial commit history.
+.Jessica's initial commit history
 image::images/managed-team-1.png[Jessica's initial commit history.]
 
 She's ready to push her work, but gets an email from Josie that a branch with some initial ``featureB'' work on it was already pushed to the server as the `featureBee` branch.
@@ -480,20 +480,20 @@ To jessica@githost:simplegit.git
 
 Jessica's commit history now looks something like this:
 
-.Jessica's history after committing on a feature branch.
+.Jessica's history after committing on a feature branch
 image::images/managed-team-2.png[Jessica's history after committing on a feature branch.]
 
 At some point, Jessica, Josie, and John inform the integrators that the `featureA` and `featureBee` branches on the server are ready for integration into the mainline.
 After the integrators merge these branches into the mainline, a fetch will bring down the new merge commit, making the history look like this:
 
-.Jessica's history after merging both her topic branches.
+.Jessica's history after merging both her topic branches
 image::images/managed-team-3.png[Jessica's history after merging both her topic branches.]
 
 Many groups switch to Git because of this ability to have multiple teams working in parallel, merging the different lines of work late in the process.
 The ability of smaller subgroups of a team to collaborate via remote branches without necessarily having to involve or impede the entire team is a huge benefit of Git.
 The sequence for the workflow you saw here is something like this:
 
-.Basic sequence of this managed-team workflow.
+.Basic sequence of this managed-team workflow
 image::images/managed-team-flow.png[Basic sequence of this managed-team workflow.]
 
 [[_public_project]]
@@ -590,7 +590,7 @@ $ git fetch origin
 
 Now, each of your topics is contained within a silo -- similar to a patch queue -- that you can rewrite, rebase, and modify without the topics interfering or interdepending on each other, like so:
 
-.Initial commit history with `featureB` work.
+.Initial commit history with `featureB` work
 image::images/public-small-1.png[Initial commit history with `featureB` work.]
 
 Let's say the project maintainer has pulled in a bunch of other patches and tried your first branch, but it no longer cleanly merges.
@@ -606,7 +606,7 @@ $ git push -f myfork featureA
 This rewrites your history to now look like <<psp_b>>.
 
 [[psp_b]]
-.Commit history after `featureA` work.
+.Commit history after `featureA` work
 image::images/public-small-2.png[Commit history after `featureA` work.]
 
 Because you rebased the branch, you have to specify the `-f` to your push command in order to be able to replace the `featureA` branch on the server with a commit that isn't a descendant of it.
@@ -632,7 +632,7 @@ Also the `--no-commit` option can be useful to delay the merge commit in case of
 
 At this point, you can notify the maintainer that you've made the requested changes, and that they can find those changes in your `featureBv2` branch.
 
-.Commit history after `featureBv2` work.
+.Commit history after `featureBv2` work
 image::images/public-small-3.png[Commit history after `featureBv2` work.]
 
 [[_project_over_email]]

book/05-distributed-git/sections/distributed-workflows.asc

@@ -14,7 +14,7 @@ In centralized systems, there is generally a single collaboration model -- the c
 One central hub, or _repository_, can accept code, and everyone synchronizes their work with it.
 A number of developers are nodes -- consumers of that hub -- and synchronize with that centralized location.
 
-.Centralized workflow.
+.Centralized workflow
 image::images/centralized_workflow.png[Centralized workflow.]
 
 This means that if two developers clone from the hub and both make changes, the first developer to push their changes back up can do so with no problems.
@@ -52,7 +52,7 @@ The process works as follows (see <<wfdiag_b>>):
 6.  The maintainer pushes merged changes to the main repository.
 
 [[wfdiag_b]]
-.Integration-manager workflow.
+.Integration-manager workflow
 image::images/integration-manager.png[Integration-manager workflow.]
 
 (((forking)))
@@ -77,7 +77,7 @@ The process works like this (see <<wfdiag_c>>):
 4.  Finally, the dictator pushes that `master` branch to the reference repository so the other developers can rebase on it.
 
 [[wfdiag_c]]
-.Benevolent dictator workflow.
+.Benevolent dictator workflow
 image::images/benevolent-dictator.png[Benevolent dictator workflow.]
 
 This kind of workflow isn't common, but can be useful in very big projects, or in highly hierarchical environments.