On 12/19/2013 07:40 AM, John Maddock wrote:
BTW I have every library set explicitly to either "develop" or "master".
IMO for libraries that you're not working on the best thing is to use whatever the superproject uses and not bother with branches. We might set the submodules to a different commit for some reason, so you could end up developing against the wrong version of a module.
Although on first glance this feels wrong, it's also what I've come to accept as the right approach. Check out a branch only when you're working in a module. At any point, you can use: git submodule summary to identify the practical differences between your workspace and the superproject configuration.
OK, in other words basically ignore the issue?
Not entirely. I just refreshed after the tools/build update with the two commands: git pull git submodule update all at the top level. Because of the way the submodules are defined, this also pulled all the submodules. The submodule update step is required to change the workspace contents, as documented for --recurse-submodules in git pull --help. These two steps fixed tools/build to have the right thing without any of the manual steps suggested in the "improving the history" thread. Peter