How to fix modified content in Git

GitINTERMEDIATELOWUpdated Dec 6, 2025ยท 244 views

This status appears in 'git status' when a submodule's working directory contains uncommitted changes or has checked out a different commit than what the parent repository expects. The fix involves either updating, committing, or resetting the submodule.

Quick fix

Fixes modified content

cd path/to/submodule
git status
git diff
  1. Check what's changed inside the submodule
  2. Reset the submodule to the expected commit
  3. Force reset the submodule (discard all local changes)
  4. Reset all submodules at once
git โ€” error
cd path/to/submodule
git status
git diff
modified content

What this error means

When you run `git status` in your main repository and see "(modified content)" next to a submodule path, it means the submodule's working directory has changes that differ from what Git expects. This is often called a "dirty" submodule. A submodule is considered "dirty" when: - Files inside the submodule have been modified but not committed - New untracked files exist in the submodule directory - The submodule HEAD points to a different commit than what the parent repository has recorded Git tracks submodules by storing a reference to a specific commit SHA in the parent repository. When you clone or update a project with submodules, Git checks out each submodule at its recorded commit. If anything changes inside the submodule directory - whether through manual edits, running build commands that generate files, or checking out a different branch - Git will mark it as having "modified content." This behavior helps ensure that everyone working on the project uses the exact same version of each submodule, but it can be confusing when the status appears unexpectedly.

Typical symptoms

  • Running 'git status' shows submodule paths with '(modified content)' annotation
  • The submodule appears in 'Changes not staged for commit' section
  • 'git diff' shows the submodule as changed even though you haven't touched it
  • Running 'git submodule status' shows a '+' prefix before the submodule commit hash
  • CI/CD pipelines fail due to unexpected submodule state

Common causes

  1. Files inside the submodule have been modified but not committed
  2. Build artifacts or generated files were created inside the submodule directory
  3. The submodule was manually checked out to a different branch or commit
  4. Running 'git submodule update --remote' pulled newer commits
  5. File permission changes occurred (especially on systems with filemode enabled)
  6. Line ending differences between platforms (CRLF vs LF)

How to fix "modified content"

1Check what's changed inside the submodule

First, navigate to the submodule directory and see what Git thinks has changed:

bash
cd path/to/submodule
git status
git diff

This shows you whether there are:
- Modified files (local edits)
- Untracked files (new files not in the submodule's .gitignore)
- A detached HEAD at a different commit

Understanding the cause helps you choose the right fix.

2Reset the submodule to the expected commit

If you want to discard all changes and return the submodule to the exact state the parent repository expects:

bash
git submodule update --checkout

Or for all submodules recursively:

bash
git submodule update --checkout --recursive

This checks out the commit SHA that the parent repository has recorded for each submodule.

3Force reset the submodule (discard all local changes)

If the regular update doesn't work because of local modifications, use the force flag:

bash
git submodule update --force --recursive

Or reset changes manually inside the submodule:

bash
cd path/to/submodule
git checkout .
git clean -fd

Warning: This discards all uncommitted changes in the submodule.

4Reset all submodules at once

To reset all submodules in your project to their clean state:

bash
git submodule foreach --recursive git checkout .
git submodule foreach --recursive git clean -fd

This runs the checkout and clean commands inside each submodule directory.

5Commit the submodule changes (if intentional)

If you intentionally updated the submodule to a new commit and want to record this in the parent repository:

bash
# First, commit any changes inside the submodule
cd path/to/submodule
git add .
git commit -m "Your changes"
git push

# Then, update the parent repository to point to the new commit
cd ..
git add path/to/submodule
git commit -m "Update submodule to latest version"

The parent repository stores only the commit reference, not the submodule's files.

6Ignore dirty submodules (hide the status)

If you want Git to stop showing "modified content" for submodules with local changes, add the ignore setting to your .gitmodules file:

ini
[submodule "path/to/submodule"]
    path = path/to/submodule
    url = https://github.com/example/repo.git
    ignore = dirty

Or set it via command line:

bash
git config -f .gitmodules submodule.path/to/submodule.ignore dirty

Options for ignore:
- untracked: Ignore only untracked files
- dirty: Ignore all working tree changes
- all: Ignore all changes including new commits

7Use command-line flag to ignore in status

For a quick one-time check without seeing dirty submodules:

bash
git status --ignore-submodules=dirty

Or to ignore all submodule changes:

bash
git status --ignore-submodules=all

You can also set this as your default behavior:

bash
git config --global diff.ignoreSubmodules dirty
8Check for nested .git directories

Sometimes "modified content" appears when there's an accidental nested Git repository. Check if there's a .git folder inside a regular directory:

bash
find . -name ".git" -type d

If you find unexpected .git directories that aren't proper submodules, you may need to either:
- Remove the nested .git folder and add the files normally
- Convert the directory to a proper submodule using git submodule add

Advanced notes

Understanding Submodule State Indicators:

When you run git submodule status, the prefix character tells you the state:
- (space): Submodule is at the expected commit
- +: Submodule is checked out to a different commit
- -: Submodule is not initialized
- U: Submodule has merge conflicts

Detached HEAD in Submodules:

By default, git submodule update checks out submodules in "detached HEAD" state, pointing to the specific commit recorded in the parent repository. This is intentional - it ensures reproducible builds. If you see "HEAD detached at <commit>" when entering a submodule, this is normal behavior, not an error.

CI/CD Considerations:

In CI/CD pipelines, always use:

bash
git submodule update --init --recursive

This ensures all submodules are properly initialized and checked out to their expected commits, avoiding "modified content" issues during builds.

Line Ending Issues:

If you're working across Windows and Unix systems, line ending differences can cause submodules to appear dirty. Configure Git to handle this:

bash
git config --global core.autocrlf input  # On Unix/Mac
git config --global core.autocrlf true   # On Windows

Filemode Changes:

On some systems (especially when sharing files between Windows and WSL), file permission changes can mark submodules as dirty. Disable filemode tracking if this is causing issues:

bash
cd path/to/submodule
git config core.filemode false

Frequently asked questions

What does "modified content" mean?
When you run git status in your main repository and see "(modified content)" next to a submodule path, it means the submodule's working directory has changes that differ from what Git expects. This is often called a "dirty" submodule. A submodule is considered "dirty" when: - Files inside the submodule have been modified but not committed - New untracked files exist in the submodule directory - The submodule HEAD points to a different commit than what the parent repository has recorded Git tracks submodules by storing a reference to a specific commit SHA in the parent repository.
How do I fix "modified content"?
This status appears in 'git status' when a submodule's working directory contains uncommitted changes or has checked out a different commit than what the parent repository expects. The fix involves either updating, committing, or resetting the submodule.
What causes "modified content"?
Files inside the submodule have been modified but not committed Build artifacts or generated files were created inside the submodule directory The submodule was manually checked out to a different branch or commit
Is the "modified content" error serious?
It is a low-severity error โ€” more of a blocker than a risk. The steps above resolve it.

Official resources & further reading