Re: Add an option to automatically submodule update on checkout

On Mon, May 8, 2017 at 7:42 AM, Randall S. Becker
[off-list ref] wrote:

On May 6, 2017 4:38 AM Ciro Santilli wrote:

quoted

This is a must if you are working with submodules, otherwise every git checkout requires a git submodule update,
and you forget it, and things break, and you understand, and you go to stack overflow questions
http://stackoverflow.com/questions/22328053/why-doesnt-git-checkout-automatically-do-git-submodule-update-recursive
http://stackoverflow.com/questions/4611512/is-there-a-way-to-make-git-pull-automatically-update-submodules
and you give up and create aliases :-)

The upcoming release (2.13) will have "git checkout --recurse-submodules",
which will checkout the submodules at the commit as recorded in the
superproject.

I plan to add an option "submodule.recurse" (name is subject to bikeshedding),
which would make the --recurse-submodules flag given by default for all commands
that support the flag. (Currently cooking we have reset
--recurse-submodules, already
existing there is push/pull).

I rather like the concept of supporting --recurse-submodules. The complexity is that the branches in all submodules all have to have compatible semantics when doing the checkout, which is by no means guaranteed. In the scenario where you are including a submodule from a third-party (very common - see gnulib), the branches likely won't be there, so you have a high probability of having the command fail or produce the same results as currently exists if you allow the checkout even with problems (another option?). If you have control of everything, then this makes sense.

I am trying to give the use case of having control over everything
(or rather mixed) more thought as well,
e.g. "checkout --recurse-submodules -b <name>" may want to
create the branches in a subset of submodules as well.

Thanks,
Stefan

Cheers,
Randall