Why doesn't `git checkout` automatically do `git submodule update --recursive`?

Someone please help me understand submodules in git. I know they are getting a lot of bashing around the internet but since I assume the git developers are smart people there must a reason for the current behavior - and maybe a way to work around my problem.

So, I have a project and some submodules. The project have different branches, like:

• MyApp_version2
• MyApp_version3
• MyApp_version4
• MyApp_liteversion
• MyApp_development

My submodules doesn't update that often (maybe once a week) so I'm fine with them not being attached to the head of the submodule repository automatically.

However, when I check out an old branch - because I need to fix a bug in an old version of the software - I also need to update the submodules.

Why do I need to do this?

I would expect git to work like svn. When I commit my work in my main repo I would expect git to think something along these lines: "OK, he wants to commit his work now. I can see the submodules are currently at revision abc so when he at some point in the future get's back to this commit he probably wants the submodules at the same revision again."

I can not see a single case where you would want the submodules to stay at the current revision while you go back 3 years in your main repository. However, there must be a reason for this implementation, right?

I would really like to hear if any of you know the thoughts behind this, but in any case I would really like a solution. Is there a way to tell git: "I want to commit this work with these submodules. If I at some point go back to this state I want the submodules to be checked out at the correct version as well."

Example for clarification

My main repository is an application which needs to use SSL, and I find a SSL library (libSSL) I add as a submodule.

On Oct. 31 2010 I create a commit in my main repository (2fd4e1) while the submodule points to libSSL version 3 (c67a2d).

Time passes, libSSl gets updated to version 34, I adapt my code, life it good.

On May 14 2013 I create a new commit (28fced) and submodule points to the most recent version of libSSL (849ee1).

However, if I check out 2fd4e1 my submodule will stay at 849ee1 even though the original commit was created with c67a2d. Git knows I made the original commit with c67a2d and I don't see how you could possibly want a another submodule than the one the original commit was created with.

It sounds like what you want to do can be achieved from git v2.13 on with the new --recurse-submodules option of git checkout. From the git-checkout manual page:

> --[no-]recurse-submodules > >Using --recurse-submodules will update the content of all initialized submodules according to the commit recorded in the superproject. If local modifications in a submodule would be overwritten the checkout will fail unless -f is used. If nothing (or --no-recurse-submodules) is used, the work trees of submodules will not be updated.

See also this relevant git mailing list message about that new option.

Simplify your shortcut/aliases by using :

alias checkitout='git checkout $1; git submodule update --recursive'

You basically want git to do all operations recursively and automatically for all submodules. Which is probably trivial in a centralized client-server model like svn.

But git is distributed. Your submodule may come from a totally different URL, with a totally different protocol. Most probably you don't event have push access to the submodule's origin repo, while you do for the main repo.

So there cannot be a recursive push.

Therefore the designers probably decided to avoid automatic recursion for submodules everywhere. Which is consistent, but a huge amount of pain.

So much so, that in a certain project we completely abandoned them and used subtree merges instead.