So let’s say you have some big codebase in Git repository. Or maybe not even that big, but with a complex dependency added in as a submodule. And this submodule is complex enough that it makes sence for it to reference other project and include them as submodules, too. Sounds too complex? Well, maybe it is, but there’re certain situations when this workflow is plausible, especially if your upstream uses Subversion instead of Git. Symfony comes to mind as an example – huge framework with a number of dependencies (look at version 1.2) that uses svn for development.
You’ve found a good guy at GitHub doing svn clone of upstream’s repository periodically, you’ve pulled his git repo as a submodule, initialized and updates submodules and things look good so far. Feeling lucky, you’re dropping in you Capistrano config, customizing it with your server and repository details, and finally typing your magical “cap deploy”. Still feeling lucky and going to grab that hard-earned cup of coffee? Well, hold on there for a minute and pay some attention. Whooops! What’s this? That bloody thing fails.
The problem here is that Capistrano by default (by that I mean when you have :git_enable_submodules settings in your config file) only issues “git submodule init && git submodule update” at the root of your checked out repository, so if you application depends on any submodules down the tree to be initialized, too – well, “Screeewed!” © GoW2