Menu
Someone please help me understand submodules in git. I know they are getting a lot of bashing around the internet but since I assume the git developers are smart people there must a reason for the current behavior - and maybe a way to work around my problem.
So, I have a project and some submodules. The project have different branches, like:
My submodules doesn't update that often (maybe once a week) so I'm fine with them not being attached to the head of the submodule repository automatically.
However, when I check out an old branch - because I need to fix a bug in an old version of the software - I also need to update the submodules.
Why do I need to do this?
I would expect git to work like svn. When I commit my work in my main repo I would expect git to think something along these lines: "OK, he wants to commit his work now. I can see the submodules are currently at revision abc so when he at some point in the future get's back to this commit he probably wants the submodules at the same revision again."
I can not see a single case where you would want the submodules to stay at the current revision while you go back 3 years in your main repository. However, there must be a reason for this implementation, right?
I would really like to hear if any of you know the thoughts behind this, but in any case I would really like a solution. Is there a way to tell git: "I want to commit this work with these submodules. If I at some point go back to this state I want the submodules to be checked out at the correct version as well."
Example for clarification
My main repository is an application which needs to use SSL, and I find a SSL library (libSSL) I add as a submodule.
On Oct. 31 2010 I create a commit in my main repository (2fd4e1) while the submodule points to libSSL version 3 (c67a2d).
Time passes, libSSl gets updated to version 34, I adapt my code, life it good.
On May 14 2013 I create a new commit (28fced) and submodule points to the most recent version of libSSL (849ee1).
However, if I check out 2fd4e1 my submodule will stay at 849ee1 even though the original commit was created with c67a2d. Git knows I made the original commit with c67a2d and I don't see how you could possibly want a another submodule than the one the original commit was created with.
829
Starting with Git 1.7. 5 it should update submodules automatically by default like you want it to.
It automatically pulls in the submodule data assuming you have already added the submodules to the parent project. Note that --recurse-submodules and --recursive are equivalent aliases.
git clone(1) --recursive. Clone a repository into a new directory. --recursive, --recurse-submodules After the clone is created, initialize all submodules within, using their default settings. This is equivalent to running git submodule update --init --recursive immediately after the clone is finished.
git submodule update --init --recursive --remote - updates all submodules recursively along their tracking branches. Without the --remote , it'll reset the submodule working directories to the "right" commit for the parent.
It sounds like what you want to do can be achieved from git v2.13 on with the new --recurse-submodules option of git checkout. From the git-checkout manual page:
--[no-]recurse-submodules
Using --recurse-submodules will update the content of all initialized submodules according to the commit recorded in the superproject. If local modifications in a submodule would be overwritten the checkout will fail unless -f is used. If nothing (or --no-recurse-submodules) is used, the work trees of submodules will not be updated.
See also this relevant git mailing list message about that new option.
199
Simplify your shortcut/aliases by using :
alias checkitout='git checkout $1; git submodule update --recursive' If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With
