+++ b/contrib/subtree/git-subtree.1
+.\" Author: [see the "AUTHOR" section]
+.\" Generator: DocBook XSL Stylesheets v1.79.1 <http://docbook.sf.net/>
+.TH "GIT\-SUBTREE" "1" "10/30/2017" "Git 2\&.17\&.0" "Git Manual"
+.\" -----------------------------------------------------------------
+.\" * Define some portability stuff
+.\" -----------------------------------------------------------------
+.\" ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+.\" http://bugs.debian.org/507673
+.\" http://lists.gnu.org/archive/html/groff/2009-02/msg00013.html
+.\" ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+.\" -----------------------------------------------------------------
+.\" * set default formatting
+.\" -----------------------------------------------------------------
+.\" disable justification (adjust text to left margin only)
+.\" -----------------------------------------------------------------
+.\" * MAIN CONTENT STARTS HERE *
+.\" -----------------------------------------------------------------
+git-subtree \- Merge subtrees together and split repository into subtrees
+\fIgit subtree\fR add \-P <prefix> <commit>
+\fIgit subtree\fR add \-P <prefix> <repository> <ref>
+\fIgit subtree\fR pull \-P <prefix> <repository> <ref>
+\fIgit subtree\fR push \-P <prefix> <repository> <ref>
+\fIgit subtree\fR merge \-P <prefix> <commit>
+\fIgit subtree\fR split \-P <prefix> [OPTIONS] [<commit>]
+Subtrees allow subprojects to be included within a subdirectory of the main project, optionally including the subproject\(cqs entire history\&.
+For example, you could include the source code for a library as a subdirectory of your application\&.
+Subtrees are not to be confused with submodules, which are meant for the same task\&. Unlike submodules, subtrees do not need any special constructions (like \&.gitmodule files or gitlinks) be present in your repository, and do not force end\-users of your repository to do anything special or to understand how subtrees work\&. A subtree is just a subdirectory that can be committed to, branched, and merged along with your project in any way you want\&.
+They are also not to be confused with using the subtree merge strategy\&. The main difference is that, besides merging the other project as a subdirectory, you can also extract the entire history of a subdirectory from your project and make it into a standalone project\&. Unlike the subtree merge strategy you can alternate back and forth between these two operations\&. If the standalone library gets updated, you can automatically merge the changes into your project; if you update the library inside your project, you can "split" the changes back out again and merge them back into the library project\&.
+For example, if a library you made for one application ends up being useful elsewhere, you can extract its entire history and publish that as its own git repository, without accidentally intermingling the history of your application project\&.