SYNOPSIS
--------
[verse]
-'git pull' [options] [<repository> [<refspec>...]]
+'git pull' [<options>] [<repository> [<refspec>...]]
DESCRIPTION
--[no-]recurse-submodules[=yes|on-demand|no]::
This option controls if new commits of all populated submodules should
- be fetched too (see linkgit:git-config[1] and linkgit:gitmodules[5]).
- That might be necessary to get the data needed for merging submodule
- commits, a feature Git learned in 1.7.3. Notice that the result of a
- merge will not be checked out in the submodule, "git submodule update"
- has to be called afterwards to bring the work tree up to date with the
- merge result.
+ be fetched and updated, too (see linkgit:git-config[1] and
+ linkgit:gitmodules[5]).
++
+If the checkout is done via rebase, local submodule commits are rebased as well.
++
+If the update is done via merge, the submodule conflicts are resolved and checked out.
Options related to merging
~~~~~~~~~~~~~~~~~~~~~~~~~~
include::merge-options.txt[]
-r::
---rebase[=false|true|preserve|interactive]::
+--rebase[=false|true|merges|preserve|interactive]::
When true, rebase the current branch on top of the upstream
branch after fetching. If there is a remote-tracking branch
corresponding to the upstream branch and the upstream branch
was rebased since last fetched, the rebase uses that information
to avoid rebasing non-local changes.
+
+When set to `merges`, rebase using `git rebase --rebase-merges` so that
+the local merge commits are included in the rebase (see
+linkgit:git-rebase[1] for details).
++
When set to preserve, rebase with the `--preserve-merges` option passed
to `git rebase` so that locally created merge commits will not be flattened.
+