I have a project that has specified submodules in it. Everything works well on the dev machine. I have commited .gitmodules file and pulled on the production. However it does not pulled submodules.
If I go into submodule directories and call git pull, nothing happens.
What is the proper way to pull those submodules in the new project ?
From the root of the repo just run:
git submodule update --init
git pull --recurse-submodules
git submodule update --init works fine in git version 2.31.1; it cloned all submodules.
git submodule update --init worked and git pull --recurse-submodules did not.
git pull --recurse-submodules will not clone the dependencies but only pull new commits, cf git pull --help: « Using --recurse-submodules can only fetch new commits in already checked out submodules right now ». Hence, to « pull » the dependencies (eg if --recurse-submodules was forgotten when cloning) you will have to use git submodule update --init --recursive (the --recursive to also clone/pull nested submodules as shown by @Iglesk)If there are nested submodules, you will need to use:
git submodule update --init --recursive
If you need to pull stuff for submodules into your submodule repositories use
git pull --recurse-submodules
But this will not checkout proper commits(the ones your master repository points to) in submodules
To checkout proper commits in your submodules you should update them after pulling using
git submodule update --recursive
git submodule update --recursive is what I needed after first git cloneing but forgetting to --recursive on the first go. Thanks!
git submodule update --init --recursive solve my issue
git submodule update --init did it for me - no --recursive necessary.I just want to share these.
First way,
git submodule init && git submodule update
The below is just basically combining the first way,
git submodule update --init
If there are any nested submodules, Iglesk's answer is the way to go.
If a repository is already cloned:
git submodule add [email protected]:sohale/bash-stash.git external/bash-stash
The submodules still need to be synced, re-initialized (since your local .git/config file would not be synced) and pulled recursively:
git pull
git submodule init
git submodule update --recursive
Following @mufidu's answer, I separated the main part into two steps.
The third line, updates your local .git/config (untracked) file by copying information about the submodule into it -- based on the .gitmodules file. It doesn't actually update any tracked file or code or the content of the submodules.
Note that since you already have cloned, the local .git/config file (which is like a cache), most likely will be out of sync (and incorrect) and won't be fixed otherwise.
The first line, git pull ..., is to emphasize that it is already cloned, and to cover the answers that suggested git pull --recurse-submodules.
I kept getting a [email protected]: Permission denied (publickey) when calling git submodule update --init --recursive as specified by @Iglesk on Windows.
The SSH config on Windows kept trying to use a specific configured key, id_rsa, and as a result without the required password - failed the authentication, preventing the submodules from being pulled.
I tried after configuring ssh configs, passing in ssh keys, and even authenticating before calling git submodule update --init --recursive - nothing worked.
I opted to use Git Bash
git submodule update --init --recursiveThat worked for me. I know its not the most future proof solution but if you're sick of the configuration and need to do it quick and dirty, that worked for me.
Notable resources I found whilst troubleshooting:
Hope this helps, dankie baie
