Pull git submodules after cloning project from GitHub

Question

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 ?

Reconnoiter

Answer 1

From the root of the repo just run:

git submodule update --init

Dermot

I believe this will actually update your dependencies. I think S. Russel had the right command in his comment below: git pull --recurse-submodules – Tedious

@Tedious command git submodule update --init works fine in git version 2.31.1; it cloned all submodules. – Impetigo

@Tedious for me git submodule update --init worked and git pull --recurse-submodules did not. – Lewandowski

@Tedious those two commands are not equivalent as 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) – Blende

Answer 2

If there are nested submodules, you will need to use:

git submodule update --init --recursive

Binns

Think that's the most complete and compact answer! Any known drawback? – Calesta

Answer 3

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

Bobsled

git submodule update --recursive is what I needed after first git cloneing but forgetting to --recursive on the first go. Thanks! – Broddy

This doesn't seem to work for me. The submodules remain empty. – Coral

@Coral same to me. – Scientific

might be too late to the party but for anyone ended up here: git submodule update --init --recursive solve my issue – Binns

Just git submodule update --init did it for me - no --recursive necessary. – Hetman

Answer 4

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.

Isopiestic

Answer 5

For the sake of completion, I combined the answers to cover recursive cases too, hopefully, this can serve as a complete answer for the community.

Since you've previously cloned a repository, the submodules need to be properly 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 wo steps.

The second 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.

Diapause