Equivalent of "svn update"?
I've followed the instructions at https://svn.boost.org/trac/boost/wiki/TryModBoost and everything worked fine. I then switched to branch develop in libs/bind and libs/smart_ptr, did developmental things there. Switched to master, did a merge, switched back to develop, did more things, git pushed the changes. This also worked fine. Now, what do I need to do to achieve the equivalent of "svn update", that is, to update all other libraries to reflect changes that others might have done in the meantime? When I do "git status" at the "modular-boost" directory (which I've named "boost"), I get: C:\Projects\boost-git\boost>git status # On branch master # Changes not staged for commit: # (use "git add <file>..." to update what will be committed) # (use "git checkout -- <file>..." to discard changes in working directory) # (commit or discard the untracked or modified content in submodules) # # modified: libs/bind (new commits) # modified: libs/smart_ptr (new commits) # modified: tools/build (untracked content) # # Untracked files: # (use "git add <file>..." to include in what will be committed) # # b2.exe # bin.v2/ # bjam.exe # boost/ # bootstrap.log # project-config.jam no changes added to commit (use "git add" and/or "git commit -a") That looks correct. Now, what do I need to do to update the master and all submodules to their latest state? Is it "git submodule update --init", "git pull", or something else? And would I then need to again checkout develop (or master, if I happen to be on that branch) in libs/bind and libs/smart_ptr?
From: lists@pdimov.com To: boost@lists.boost.org Date: Sat, 7 Dec 2013 21:45:20 +0200 Subject: [boost] Equivalent of "svn update"?
I've followed the instructions at https://svn.boost.org/trac/boost/wiki/TryModBoost and everything worked fine.
I then switched to branch develop in libs/bind and libs/smart_ptr, did developmental things there. Switched to master, did a merge, switched back to develop, did more things, git pushed the changes. This also worked fine.
Now, what do I need to do to achieve the equivalent of "svn update", that is, to update all other libraries to reflect changes that others might have done in the meantime?
When I do "git status" at the "modular-boost" directory (which I've named "boost"), I get:
C:\Projects\boost-git\boost>git status # On branch master # Changes not staged for commit: # (use "git add <file>..." to update what will be committed) # (use "git checkout -- <file>..." to discard changes in working directory) # (commit or discard the untracked or modified content in submodules) # # modified: libs/bind (new commits) # modified: libs/smart_ptr (new commits) # modified: tools/build (untracked content) # # Untracked files: # (use "git add <file>..." to include in what will be committed) # # b2.exe # bin.v2/ # bjam.exe # boost/ # bootstrap.log # project-config.jam no changes added to commit (use "git add" and/or "git commit -a")
That looks correct. Now, what do I need to do to update the master and all submodules to their latest state? Is it "git submodule update --init", "git pull", or something else? And would I then need to again checkout develop (or master, if I happen to be on that branch) in libs/bind and libs/smart_ptr?
The steps are (I think, mostly exhaustively): 1. Decide whether you want to test against the develop branch of other libs or the master branch. 2. Run in the super project: git checkout <branch> git pull git submodule update # this will change bind and smart_ptr to some other checkin cd libs/bind git checkout develop cd ../smart_ptr git checkout develop 3. Run your tests. I haven't tested this exact sequence, but I've done things that are similar. If something goes wrong, just send another mail.
For information, you can update all the submodules to their latest version with: git submodule foreach git pull "foreach" is very useful to manipulate all submodules at once. HIH, Philippe
Philippe Vaucher wrote:
For information, you can update all the submodules to their latest version with:
git submodule foreach git pull
"git pull" is a no-op for a detached HEAD, is it not? The above would work if I switch all submodules to a branch first: git submodule foreach git checkout develop but not by default.
On 7 December 2013 22:53, Peter Dimov
Philippe Vaucher wrote:
For information, you can update all the submodules to their latest version with:
git submodule foreach git pull
"git pull" is a no-op for a detached HEAD, is it not? The above would work if I switch all submodules to a branch first:
git submodule foreach git checkout develop
but not by default.
This manpage contains some useful information, and is a lot shorter than the git-submodule page: https://www.kernel.org/pub/software/scm/git/docs/gitmodules.html Especially that 'git submodule update --init --merge' will merge your changes with the update. I haven't tried it yet so I don't know how well it works.
Ahmed Charles wrote:
2. Run in the super project: git checkout <branch> git pull git submodule update # this will change bind and smart_ptr to some other checkin cd libs/bind git checkout develop cd ../smart_ptr git checkout develop
This works, thanks. Daniel James wrote:
This manpage contains some useful information, and is a lot shorter than the git-submodule page:
https://www.kernel.org/pub/software/scm/git/docs/gitmodules.html
Especially that 'git submodule update --init --merge' will merge your changes with the update.
By the description, it looks like using --merge in the above procedure will leave libs/bind and libs/smart_ptr on develop, but I'm not sure what it will do to the rest; the alternative is for me to add update = merge to [submodule "bind"] and [submodule "smart_ptr"] in .gitmodules. Not sure if this is worth the bother. It's not that hard to manually checkout these two after update. Let's see first what the testing infrastructure will do. :-)
Peter Dimov wrote:
Daniel James wrote:
This manpage contains some useful information, and is a lot shorter than the git-submodule page:
https://www.kernel.org/pub/software/scm/git/docs/gitmodules.html
Especially that 'git submodule update --init --merge' will merge your changes with the update.
By the description, it looks like using --merge in the above procedure will leave libs/bind and libs/smart_ptr on develop, but I'm not sure what it will do to the rest; ...
I can answer my own question now. It inserts unwanted and unnecessary local merge commits in submodules which leaves one baffled for a few minutes when git says "your local branch is ahead of origin by 134 commits". :-)
On 13 December 2013 20:12, Peter Dimov
Peter Dimov wrote:
Daniel James wrote:
This manpage contains some useful information, and is a lot shorter than
the git-submodule page:
https://www.kernel.org/pub/software/scm/git/docs/gitmodules.html
Especially that 'git submodule update --init --merge' will merge your > changes with the update.
By the description, it looks like using --merge in the above procedure will leave libs/bind and libs/smart_ptr on develop, but I'm not sure what it will do to the rest; ...
I can answer my own question now. It inserts unwanted and unnecessary local merge commits in submodules which leaves one baffled for a few minutes when git says "your local branch is ahead of origin by 134 commits". :-)
I did say that I didn't know if it would work. I guess the best thing to do is to configure the super project to do whatever it is that you want.
participants (4)
-
Ahmed Charles -
Daniel James -
Peter Dimov -
Philippe Vaucher