[git] Getting set up to test?
Before making changes to, say, the develop branch of a library, I want to set the super-project to the latest master so tests run in the most realistic environment, as Robert Ramey has advocated for years. Presumably that means doing something like this: cd modular-boost git checkout master git pull --recurse-submodules cd modular-boost/libs/mylib git checkout develop Is "git pull --recurse-submodules" the correct command to update the submodules? Do I also need to do "git submodule update" or possibly "git submodule update --remote"? Thanks, --Beman
On Sat, Dec 14, 2013 at 6:55 AM, Beman Dawes
Before making changes to, say, the develop branch of a library, I want to set the super-project to the latest master in the submodules so tests run in the most realistic environment, as Robert Ramey has advocated for years.
Presumably that means doing something like this:
cd modular-boost
git checkout master
git pull --recurse-submodules cd modular-boost/libs/mylib git checkout develop
Is "git pull --recurse-submodules" the correct command to update the submodules?
The way this command works has changed depending on the git version (see P.S. below).
Do I also need to do "git submodule update" or possibly "git submodule update --remote"?
The "git submodule update" seems like the *wrong* command to use. It will update the the last committed submodule references (gitlinks) which may not be the same as the HEAD for master of the submodules. I'm not sure I understand the --remote option yet. I find the following sequence more intuitive and probably less git version dependent: cd modular-boost git checkout master git pull # updates the superproject (assuming origin points to boostorg and branch.master.remote=origin and is tracking origin/master). git submodule foreach --recursive "git checkout master; git pull" cd libs/mylib git checkout develop If the "git submodule foreach..." shows some commits pulled down for a submodule, that indicates the submodule references in the superproject hasn't been properly updated to the latest HEAD in the master branch. Michael P.S. Just noticed this from the git-pull man page: --[no-]recurse-submodules[=yes|on-demand|no] This option controls if new commits of all populated submodules should be fetched too (see git-config(1) and gitmodules(5)). That might be necessary to get the data needed for merging submodule commits, a feature Git learned in 1.7.3. Notice that the result of a merge will not be checked out in the submodule, "git submodule update" has to be called afterwards to bring the work tree up to date with the merge result. Note the reference to git 1.7.3. To take advantage of the new features in git-submodule we need to make the minimum git version requirement to be
=1.7.3. If boost development requires this, we have to modify the .gitmodules in the master branch to have
branch=master and in the develop branch branch=develop _______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
participants (2)
-
Beman Dawes -
Cox, Michael