Re: [PATCH v2] pull: Document the "--[no-]recurse-submodules" options
Jens Lehmann <Jens.Lehmann@web.de> writes:
Show 17 quoted lines
> diff --git a/Documentation/fetch-options.txt b/Documentation/fetch-options.txt
> index 695696d..ab0dbfc 100644
> --- a/Documentation/fetch-options.txt
> +++ b/Documentation/fetch-options.txt
> @@ -64,11 +64,11 @@ ifndef::git-pull[]
> downloaded. The default behavior for a remote may be
> specified with the remote.<name>.tagopt setting. See
> linkgit:git-config[1].
> -endif::git-pull[]
>
> --[no-]recurse-submodules::
> This option controls if new commits of all populated submodules should
> be fetched too (see linkgit:git-config[1] and linkgit:gitmodules[5]).
> +endif::git-pull[]
>
> ifndef::git-pull[]
> --submodule-prefix=<path>::
Hmph, why not enclose the three of them inside a single ifndef here?
Show 16 quoted lines
> diff --git a/Documentation/git-pull.txt b/Documentation/git-pull.txt
> index 3046691..b33e6be 100644
> --- a/Documentation/git-pull.txt
> +++ b/Documentation/git-pull.txt
> @@ -84,6 +84,15 @@ must be given before the options meant for 'git fetch'.
> --verbose::
> Pass --verbose to git-fetch and git-merge.
>
> +--[no-]recurse-submodules::
> + 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.