0

The git-push documentation is pretty clear on the four options (using --recurse-submodules) for push's behavior when submodules are present:

  • check: Make sure submodule commits needed by the parent have been pushed; abort push if they have not
  • on-demand: Push all needed submodule commits before pushing parent commits (and fail if any fail)
  • only: Push only submodules; do not push the parent
  • no (or --no-recurse-submodules): Do not push submodules.

But what is the default? If no --recurse-submodules option is present, no --no-recurse-submodules option is present, and no push.recurseSubmodules configuration value is set, what happens? And is it the same for all Git versions?

Appendix

The documentation contains a hint that the default is no:

A value of no or using --no-recurse-submodules can be used to override the push.recurseSubmodules configuration variable when no submodule recursion is required. (emphasis added)

So if the no option is needed only when push.recurseSubmodules is set, this implies that when push.recurseSubmodules is unset, no is the default behavior. Is it?

David P. Caldwell
  • 3,394
  • 1
  • 19
  • 32

1 Answers1

0

I mentioned in "Git submodule push" that:

When push.recurseSubmodules is set to no, then default behavior of ignoring submodules when pushing is retained.

That suggests no is indeed the default behavior.

VonC
  • 1,262,500
  • 529
  • 4,410
  • 5,250
  • When fetching, on the other hand... https://github.com/git/git/blob/0aae918dd929862d3ce0ea2960897787bb269a3b/submodule.c#L1424-L1435 – VonC Dec 08 '19 at 00:32