On Mon, Apr 6, 2015 at 6:25 PM, Bruce Edge <[email protected]> wrote: > > 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
Interesting, thanks. We probably need one (or two) proofs-of-concept before settling on what to use. I would favour an OOTB solution, like git submodules, since it means less friction for contributors, if it solves the same problem as the 'external' tools. Robert > > 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
