From: Robert Munteanu <[email protected]<mailto:[email protected]>> Reply-To: "[email protected]<mailto:[email protected]>" <[email protected]<mailto:[email protected]>> Date: Monday, April 6, 2015 at 3:42 AM To: "[email protected]<mailto:[email protected]>" <[email protected]<mailto:[email protected]>> Subject: Re: [jira] [Commented] (SLING-3987) move from Subversion to Git
On Mon, 2015-04-06 at 05:35 +0000, Bruce Edge wrote: As I understand it, we want to pull in the master version of each sub-module, not a specific version. This would be analogous a single trunk checkout that we have today. The build-time bindings will still be defined in launchpad(s), as they are to day. Robert git submodule update does have a -recurse option: this command will recurse into the registered submodules, and update any nested submodules within. It's just not the default. I'm not sure I follow. AFAIU submodules ask you to specify a certain commit for a submodule, like cafebabe or 1234baab . It does not support symbolic refs like origin/master . The best that I could find is something like [1] $ git submodule foreach git pull origin master Assuming that we have a module named 'build' that aggregates all the submodules, for each commit to a submodule I would need to update the .gitmodules file and then commit the change to the 'build' repo. With gitslave or similar tools the second step is not needed. Robert [1]: http://stackoverflow.com/questions/5828324/update-git-submodule-to-latest-commit-on-origin I haven't tested it, but this should work for your use case: git submodule update --remote -merge The -remote option uses the remote's tracking branch to obtain the SHA-1 rather than the superproject's and defaults to master. It will do an implicit fetch of the remote branch to determine the current head prior to merging with the current superproject's current head of that submodule. -Bruce
