I'm not clear on what the following means (from the Git submodule update documentation):
...will make the submodules HEAD be detached, unless
--rebase
or--merge
is specified...
How does --rebase
/--merge
change things?
My main use case is to have a bunch of central repositories, which I will embed via submodules into other repositories. I would like to be able to improve on these central repositories, either directly in their original location, or from within their embedding repositories (the ones that use them via submodule).
This question is related to
git
git-submodules
To address the --rebase
vs. --merge
option:
Let's say you have super repository A and submodule B and want to do some work in submodule B. You've done your homework and know that after calling
git submodule update
you are in a HEAD-less state, so any commits you do at this point are hard to get back to. So, you've started work on a new branch in submodule B
cd B
git checkout -b bestIdeaForBEver
<do work>
Meanwhile, someone else in project A has decided that the latest and greatest version of B is really what A deserves. You, out of habit, merge the most recent changes down and update your submodules.
<in A>
git merge develop
git submodule update
Oh noes! You're back in a headless state again, probably because B is now pointing to the SHA associated with B's new tip, or some other commit. If only you had:
git merge develop
git submodule update --rebase
Fast-forwarded bestIdeaForBEver to b798edfdsf1191f8b140ea325685c4da19a9d437.
Submodule path 'B': rebased into 'b798ecsdf71191f8b140ea325685c4da19a9d437'
Now that best idea ever for B has been rebased onto the new commit, and more importantly, you are still on your development branch for B, not in a headless state!
(The --merge
will merge changes from beforeUpdateSHA to afterUpdateSHA into your working branch, as opposed to rebasing your changes onto afterUpdateSHA.)
Git 1.8.2 features a new option ,--remote
, that will enable exactly this behavior. Running
git submodule update --rebase --remote
will fetch the latest changes from upstream in each submodule, rebase them, and check out the latest revision of the submodule. As the documentation puts it:
--remote
This option is only valid for the update command. Instead of using the superproject’s recorded SHA-1 to update the submodule, use the status of the submodule’s remote-tracking branch.
This is equivalent to running git pull
in each submodule, which is generally exactly what you want.
(This was copied from this answer.)
To update each submodule, you could invoke the following command (at the root of the repository):
git submodule -q foreach git pull -q origin master
You can remove the -q option to follow the whole process.
Source: Stackoverflow.com