Sign Up to our social questions and Answers Engine to ask questions, answer people’s questions, and connect with other people.
Login to our social questions & Answers Engine to ask questions answer people’s questions & connect with other people.
Lost your password? Please enter your email address. You will receive a link and will create a new password via email.
Please briefly explain why you feel this question should be reported.
Please briefly explain why you feel this answer should be reported.
Please briefly explain why you feel this user should be reported.
I am new to git submodules, and I notice they always refer to specific commits.
Is there any way for a superproject’s submodules to always refer to the head of the master branch, so “git submodule update” or “git pull” in the superproject simply does “git pull” on all submodules.
Thanks.
The short answer is no. The idea is that you know for sure a specific commit of the submodule will work with your project, and you don’t want any undefined or unexpected behavior coming in by getting on-the-fly updates. A submodule is directly represented by two things: an entry in .gitmodules, and a gitlink, which is a reference to the SHA1 of the desired commit of the submodule. SHA1, not refname.
What you’re asking is really for the superproject to have no idea what’s in the submodule. Think about it: different clones of your project could have updated the submodule at different times, and end up with different versions of it there, and then if commits were made in your project, they’d have to record different commits in the submodule. When you merged, you’d have to just ignore what they both say and pull again, probably. The upshot is that your request is avoiding the entire idea of submodules: to know what you have. If you say you’re using “master”, you’d come back two months from now and have no idea what that meant!
If you want to always get the current master branch, you’re better off doing it yourself. Write a script to pull in all the submodules, and run it now and then, committing the updated versions. (Test first, though!) The point here is that with submodules, for every superproject commit, you must know exactly what version of the subproject you’re using. It’s your choice how often you want to update the version of the submodule; it can be daily if you like.
The alternative would be to add the directory(ies) for the submodule(s) to your gitignore, and write a quick little script to update them (and probably one to clone them too). This would cost you the ability to know what version you had at some point in the past.