from the subproject, rather than its
	entire history.

merge <local-commit> [<repository>]::
	Merge recent changes up to <local-commit> into the <prefix>
	subtree.  As with normal 'git merge', this doesn't
	remove your own local changes; it just merges those
	changes into the latest <local-commit>.  With '--squash',
	create only one commit that contains all the changes,
	rather than merging in the entire history.
+
If you use '--squash', the merge direction doesn't always have to be
forward; you can use this command to go back in time from v2.5 to v2.4,
for example.  If your merge introduces a conflict, you can resolve it in
the usual ways.
+
When using '--squash', and the previous merge with '--squash' merged an
annotated tag of the subtree repository, that tag needs to be available locally.
If <repository> is given, a missing tag will automatically be fetched from that
repository.

split [<local-commit>] [<repository>]::
	Extract a new, synthetic project history from the
	history of the <prefix> subtree of <local-commit>, or of
	HEAD if no <local-commit> is given.  The new history
	includes only the commits (including merges) that
	affected <prefix>, and each of those commits now has the
	contents of <prefix> at the root of the project instead
	of in a subdirectory.  Thus, the newly created history
	is suitable for export as a separate git repository.
+
After splitting successfully, a single commit ID is printed to stdout.
This corresponds to the HEAD of the newly created tree, which you can
manipulate however you want.
+
Repeated splits of exactly the same history are guaranteed to be
identical (i.e. to produce the same commit IDs) as long as the
settings passed to 'split' (such as '--annotate') are the same.
Because of this, if you add new commits and then re-split, the new
commits will be attached as commits on top of the history you
generated last time, so 'git merge' and friends will work as expected.
+
When a previous merge with '--squash' merged an annotated tag of the
subtree repository, that tag needs to be available locally.
If <repository> is given, a missing tag will automatically be fetched from that
repository.

pull <repository> <remote-ref>::
	Exactly like 'merge', but parallels 'git pull' in that
	it fetches the given ref from the specified remote
	repository.

push <repository> [+][<local-commit>:]<remote-ref>::
	Does a 'split' using the <prefix> subtree of <local-commit>
	and then does a 'git push' to push the result to the
	<repository> and <remote-ref>.  This can be used to push your
	subtree to different branches of the remote repository.  Just
	as with 'split', if no <local-commit> is given, then HEAD is
	used.  The optional leading '+' is ignored.

OPTIONS FOR ALL COMMANDS
------------------------
-q::
--quiet::
	Suppress unnecessary output messages on stderr.

-d::
--debug::
	Produce even more unnecessary output messages on stderr.

-P <prefix>::
--prefix=<prefix>::
	Specify the path in the repository to the subtree you
	want to manipulate.  This option is mandatory
	for all commands.

OPTIONS FOR 'add' AND 'merge' (ALSO: 'pull', 'split --rejoin', AND 'push --rejoin')
-----------------------------------------------------------------------------------
These options for 'add' and 'merge' may also be given to 'pull' (which
wraps 'merge'), 'split --rejoin' (which wraps either 'add' or 'merge'
as appropriate), and 'push --rejoin' (which wraps 'split --rejoin').

--squash::
	Instead of merging the entire history from the subtree project, produce
	only a single commit that contains all the differences you want to
	merge, and then merge that new commit into your project.
+
Using this option helps to reduce log clutter. People rarely want to see
every change that happened between v1.0 and v1.1 of the library they're
using, since none of the interim versions were ever included in their
application.
+
Using '--squash' also helps avoid problems when the same subproject is
included multiple times in the same project,