Currently the section about recursing into submodules is repeated in
git-pull word for word as it is in fetch-options.

Don't repeat ourselves here and include the --recurse-submodules via
fetch options.

As a bonus expose the --jobs parameter in git-pull as well as that is
declared as a OPT_PASSTHRU for fetch internally already.

Signed-off-by: Stefan Beller <>
 Documentation/fetch-options.txt | 2 ++
 Documentation/git-pull.txt      | 9 ---------
 2 files changed, 2 insertions(+), 9 deletions(-)

diff --git a/Documentation/fetch-options.txt b/Documentation/fetch-options.txt
index 9eab1f5..352b640 100644
--- a/Documentation/fetch-options.txt
+++ b/Documentation/fetch-options.txt
@@ -89,6 +89,7 @@ ifndef::git-pull[]
        option alone does not subject tags to pruning, even if --prune
        is used (though tags may be pruned anyway if they are also the
        destination of an explicit refspec; see `--prune`).
        This option controls if and under what conditions new commits of
@@ -108,6 +109,7 @@ ifndef::git-pull[]
        submodules will be faster. By default submodules will be fetched
        one at a time.
        Disable recursive fetching of submodules (this has the same effect as
        using the `--recurse-submodules=no` option).
diff --git a/Documentation/git-pull.txt b/Documentation/git-pull.txt
index d033b25..e4cd56a 100644
--- a/Documentation/git-pull.txt
+++ b/Documentation/git-pull.txt
@@ -84,15 +84,6 @@ OPTIONS
        Pass --verbose to git-fetch and git-merge.
-       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.
 Options related to merging

Reply via email to