delta/git.git/Documentation/git-submodule.txt, branch ew/http-backend-batch-headers

Merge branch 'sb/submodule-deinit-all'

2016-05-17T21:38:20+00:00

Correct faulty recommendation to use "git submodule deinit ." when
de-initialising all submodules, which would result in a strange
error message in a pathological corner case.

* sb/submodule-deinit-all:
  submodule deinit: require '--all' instead of '.' for all submodules

submodule deinit: require '--all' instead of '.' for all submodules

2016-05-05T21:51:26+00:00

The discussion in [1] pointed out that '.' is a faulty suggestion as
there is a corner case where it fails:

> "submodule deinit ." may have "worked" in the sense that you would
> have at least one path in your tree and avoided this "nothing
> matches" most of the time.  It would have still failed with the
> exactly same error if run in an empty repository, i.e.
>
>        $ E=/var/tmp/x/empty && rm -fr "$E" && mkdir -p "$E" && cd "$E"
>        $ git init
>        $ rungit v2.6.6 submodule deinit .
>        error: pathspec '.' did not match any file(s) known to git.
>        Did you forget to 'git add'?
>        $ >file && git add file
>        $ rungit v2.6.6 submodule deinit .
>        $ echo $?
>        0

So instead of a pathspec add the '--all' option to deinit all submodules
and add a test to check for the corner case of an empty repository.

The code only needs to learn about the '--all' option and doesn't
require further changes as `git submodule--helper list "$@"` will list
all submodules when "$@" is empty.

[1] http://news.gmane.org/gmane.comp.version-control.git/289535

Helped-by: Junio C Hamano 
Signed-off-by: Stefan Beller 
Reviewed-by: Jonathan Nieder 
Signed-off-by: Junio C Hamano

submodule update: expose parallelism to the user

2016-03-01T19:57:20+00:00

Expose possible parallelism either via the "--jobs" CLI parameter or
the "submodule.fetchJobs" setting.

By having the variable initialized to -1, we make sure 0 can be passed
into the parallel processing machine, which will then pick as many parallel
workers as there are CPUs.

Reviewed-by: Jonathan Nieder 
Signed-off-by: Stefan Beller 
Signed-off-by: Junio C Hamano

document submodule sync --recursive

2015-12-04T21:08:05+00:00

The git-submodule(1) is inconsistent. In the synopsis, it says:

       git submodule [--quiet] sync [--recursive] [--] [...]

The description of the sync does not mention --recursive, and the
description of --recursive says that it is only available for foreach,
update and status.

The option was introduced (82f49f294c, Teach --recursive to submodule
sync, 2012-10-26) a while ago, so let's document it, too.

Reported-by: Per Cederqvist 
Signed-off-by: Stefan Beller 
Signed-off-by: Junio C Hamano

submodule doc: reorder introductory paragraphs

2015-05-28T22:18:11+00:00

It's better to start the man page with a description of what
submodules actually are, instead of saying what they are not.

Reorder the paragraphs such that

 - the first short paragraph introduces the submodule concept,
 - the second paragraph highlights the usage of the submodule command,
 - the third paragraph giving background information, and finally
 - the fourth paragraph discusing alternatives such as subtrees and
   remotes, which we don't want to be confused with.

This ordering deepens the knowledge on submodules with each paragraph.
First the basic questions like "How/what" will be answered, while the
underlying concepts will be taught at a later time.

Making sure it is not confused with subtrees and remotes is not really
enhancing knowledge of submodules itself, but rather painting the big
picture of git concepts, so you could also argue to have it as the second
paragraph. Personally I think this may confuse readers, specially
newcomers though.

Additionally to reordering the paragraphs, they have been slightly
reworded.

Signed-off-by: Stefan Beller 
Signed-off-by: Junio C Hamano

submodule: improve documentation of update subcommand

2015-03-02T22:59:55+00:00

The documentation of 'git submodule update' has several problems:

1) It mentions that value 'none' of submodule.$name.update can be
   overridden by --checkout, but other combinations of configuration
   values and command line options are not mentioned.

2) The documentation of submodule.$name.update is scattered across three
   places, which is confusing.

3) The documentation of submodule.$name.update in gitmodules.txt is
   incorrect, because the code always uses the value from .git/config
   and never from .gitmodules.

4) Documentation of --force was incomplete, because it is only effective
   in case of checkout method of update.

Fix all these problems by documenting submodule.*.update in
git-submodule.txt and make everybody else refer to it.

Helped-by: Junio C Hamano 
Helped-by: Jens Lehmann 
Signed-off-by: Michal Sojka 
Signed-off-by: Junio C Hamano

Merge branch 'mc/doc-submodule-sync-recurse' into maint

2014-07-10T18:08:31+00:00

* mc/doc-submodule-sync-recurse:
  submodule: document "sync --recursive"

submodule: document "sync --recursive"

2014-06-13T22:00:17+00:00

The "git submodule sync" command supports the --recursive flag, but
the documentation does not mention this.  That flag is useful, for
example when a remote is changed in a submodule of a submodule.

Signed-off-by: Matthew Chen 
Signed-off-by: Junio C Hamano

Revert "submodule: explicit local branch creation in module_clone"

2014-04-02T21:15:36+00:00

This reverts commit 23d25e48f5ead73c9ce233986f90791abec9f1e8, as it is
broken for users who haven't opted into the new feature of checking
out submodule.*.branch with update mode set to checkout.

Revert "Merge branch 'wt/doc-submodule-name-path-confusion-2'"

2014-04-01T18:52:37+00:00

This reverts commit 00d4ff1a69883e24b095f45251d99143b5bc0320, reversing
changes made to d3badc6eb0961382788c2670129d5ee133d079fd.