On Mon, May 8, 2017 at 7:42 AM, Randall S. Becker <rsbecker@xxxxxxxxxxxxx> wrote: > On May 6, 2017 4:38 AM Ciro Santilli wrote: >> 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 >