Updating submodules in Git - Step-by-Step Execution

Process Flow - Updating submodules

Start in main repo

↓

Run git submodule update

↓

Check submodule config

↓

Fetch latest commit for submodule

↓

Checkout submodule to recorded commit

↓

Submodule updated

↓

End

This flow shows how Git updates submodules by fetching and checking out the commit recorded in the main repository.

Execution Sample

Git

git submodule update --remote
# Updates submodules to latest commit on their tracked branch

This command updates all submodules to the latest commit on their configured remote branch.

Process Table

Step	Command	Action	Submodule Commit Before	Submodule Commit After	Output
1	git submodule update --remote	Start update process	abc1234	abc1234	Fetching submodule updates...
2	git fetch origin	Fetch latest commits from submodule remote	abc1234	abc1234	From https://repo.url * branch 'main' -> FETCH_HEAD
3	git checkout origin/main	Checkout latest commit on tracked branch	abc1234	def5678	Note: checking out 'def5678'
4	Update complete	Submodule now at latest commit	abc1234	def5678	Submodule updated to def5678
5	End	No more updates	def5678	def5678	Update finished successfully

💡 Submodule commit updated from abc1234 to def5678, matching latest remote commit.

Status Tracker

Variable	Start	After Step 2	After Step 3	Final
submodule_commit	abc1234	abc1234	def5678	def5678

Key Moments - 2 Insights

Why does the submodule commit change after step 3?

Because 'git checkout origin/main' moves the submodule to the latest commit on the remote branch, updating it from the old commit (abc1234) to the new one (def5678) as shown in execution_table row 3.

What happens if you run 'git submodule update' without --remote?

It will checkout the commit recorded in the main repo, not necessarily the latest remote commit. This means the submodule commit might not change, unlike in the execution_table where --remote fetches and updates.

Visual Quiz - 3 Questions

Look at the execution table, what is the submodule commit after step 2?

A def5678

B abc1234

C origin/main

D FETCH_HEAD

💡 Hint

Check the 'Submodule Commit After' column for step 2 in the execution_table.

At which step does the submodule commit update to the latest remote commit?

A Step 1

B Step 4

C Step 3

D Step 5

💡 Hint

Look at the 'Submodule Commit After' column and see when it changes from abc1234 to def5678.

If you omit '--remote' in the update command, how would the submodule commit change?

A It would stay at the commit recorded in the main repo

B It would update to the latest remote commit anyway

C It would reset to an earlier commit

D It would delete the submodule

💡 Hint

Refer to key_moments explanation about the difference between 'git submodule update' and 'git submodule update --remote'.

Concept Snapshot

git submodule update --remote
- Fetches latest commits for submodules
- Checks out submodules to latest remote branch commit
- Updates submodule commit pointer
- Without --remote, updates to recorded commit only
- Use to keep submodules in sync with their repos

Full Transcript

This visual execution shows how the 'git submodule update --remote' command updates submodules. Starting from the main repo, the command fetches the latest commits from the submodule's remote repository. Then it checks out the submodule to the latest commit on the tracked branch, updating the submodule commit from an old commit (abc1234) to a new one (def5678). The process ends with the submodule updated successfully. Key points include understanding that without --remote, the submodule only updates to the commit recorded in the main repo, not the latest remote commit. The variable tracker shows the submodule commit changing only after the checkout step. The quiz questions reinforce these steps and differences.

Practice

1. What does the command git submodule update --init --recursive do in a Git project?

easy

A. It deletes all submodules from the project.

B. It commits changes in all submodules automatically.

C. It initializes and updates all submodules recursively after cloning the main project.

D. It creates new submodules inside the main project.

Solution

1. Step 1: Understand submodule initialization

   The --init option initializes submodules that are not yet initialized in the cloned project.

2. Step 2: Understand recursive update

   The --recursive option ensures that nested submodules inside submodules are also initialized and updated.

3. Final Answer:

   It initializes and updates all submodules recursively after cloning the main project. -> Option C

4. Quick Check:

   Initialize + recursive update = It initializes and updates all submodules recursively after cloning the main project. [OK]

Hint: Init and recursive flags together set up all submodules after clone [OK]

Common Mistakes:

• Thinking it deletes submodules
• Assuming it commits changes automatically
• Confusing initialization with creation of submodules

2. Which of the following is the correct syntax to update submodules to their latest remote commits?

easy

A. git submodule update --remote

B. git submodule update --fetch --all

C. git submodule update --recursive --commit

D. git submodule update --init

Solution

1. Step 1: Identify the command for updating to latest remote commits

   The --remote option tells Git to fetch and update submodules to the latest commit on their remote branches.

2. Step 2: Check other options for correctness

   --init only initializes, --recursive --commit is invalid syntax, and --fetch --all is not a valid submodule update option.

3. Final Answer:

   git submodule update --remote -> Option A

4. Quick Check:

   Update submodules to latest remote = --remote [OK]

Hint: Use --remote to pull latest submodule commits [OK]

Common Mistakes:

• Using --init instead of --remote
• Adding invalid flags like --commit
• Confusing fetch with update options

3. After cloning a repository with submodules, you run these commands:

git submodule update --init
cd submodule_dir
git log -1 --oneline

What will the git log -1 --oneline inside the submodule show?

medium

A. The latest commit from the submodule's remote repository.

B. The commit that the main project references for the submodule.

C. An error because the submodule is not initialized.

D. The commit history of the main project.

Solution

1. Step 1: Understand what git submodule update --init does

   This command initializes the submodule and checks out the commit that the main project references, not necessarily the latest remote commit.

2. Step 2: Analyze the git log -1 --oneline output inside submodule

   This shows the latest commit checked out in the submodule directory, which matches the main project's recorded commit, not the remote HEAD.

3. Final Answer:

   The commit that the main project references for the submodule. -> Option B

4. Quick Check:

   Submodule update checks out main project commit, not latest remote [OK]

Hint: Submodule update checks out recorded commit, not latest remote [OK]

Common Mistakes:

• Assuming submodule auto-updates to latest remote commit
• Expecting error after init command
• Confusing main project and submodule commit logs

4. You ran git submodule update --remote but the submodule did not update to the latest commit. What is a likely cause?

medium

A. The submodule directory is empty.

B. You forgot to clone the main repository first.

C. The main project has no submodules configured.

D. The submodule's remote branch is not set or tracking is missing.

Solution

1. Step 1: Understand the role of remote tracking in submodules

   The --remote option updates submodules by fetching from their configured remote branch. If this branch is not set, update won't move the commit.

2. Step 2: Check other options for relevance

   Cloning the main repo is prerequisite but unrelated to this issue; no submodules means no update; empty directory usually means uninitialized submodule.

3. Final Answer:

   The submodule's remote branch is not set or tracking is missing. -> Option D

4. Quick Check:

   Remote branch missing = no update with --remote [OK]

Hint: Ensure submodule remote branch is set for --remote updates [OK]

Common Mistakes:

• Ignoring remote branch configuration
• Assuming cloning main repo fixes submodule update
• Confusing empty directory with update failure

5. You want to clone a repository with multiple nested submodules and ensure all submodules and their nested submodules are initialized and updated to the commits recorded in the main project. Which command should you run immediately after cloning?

hard

A. git submodule update --init --recursive

B. git submodule update --remote --recursive

C. git clone --recurse-submodules --remote

D. git submodule init && git submodule update

Solution

1. Step 1: Understand cloning with submodules

   After cloning, submodules are not initialized or updated by default. The --init flag initializes them.

2. Step 2: Ensure nested submodules are handled

   The --recursive flag ensures all nested submodules are also initialized and updated to the recorded commits.

3. Step 3: Differentiate from --remote option

   --remote updates submodules to latest remote commits, not the commits recorded in the main project, so it's not suitable here.

4. Final Answer:

   git submodule update --init --recursive -> Option A

5. Quick Check:

   Init + recursive updates recorded commits after clone [OK]

Hint: Use --init and --recursive to set all submodules after clone [OK]

Common Mistakes:

• Using --remote instead of --init for recorded commits
• Forgetting recursive flag for nested submodules
• Trying to combine clone and remote flags incorrectly