Introduction

When Git shows a path with (modified content, untracked content), it is usually talking about a submodule, not an ordinary file. The parent repository is telling you that inside that submodule directory there are tracked changes and also untracked files.

So the fix is not just git add . in the parent repo. You need to inspect the submodule itself and decide whether to keep, commit, ignore, or discard the changes inside it.

Understand what the message means

You will often see something like:

modified:   vendor/libfoo (modified content, untracked content)

That means:

• the submodule working tree has tracked files that changed
• the submodule also contains files Git inside the submodule does not know about yet

The parent repository only sees that the submodule directory is dirty. It cannot automatically decide what should happen to the content inside it.

Inspect the submodule directly

First, enter the submodule and check its status:

cd vendor/libfoo
git status

This will show the real tracked modifications and the untracked files. Once you see those details, the right fix becomes much clearer.

You can also check submodule state from the parent repository:

git submodule status
git diff --submodule

These commands help when you want a quick summary before diving in.

Keep the changes if they are intentional

If the modified and untracked files are real work you want to preserve, commit them inside the submodule first:

cd vendor/libfoo
git add .
git commit -m "Update libfoo configuration"

Then go back to the parent repository and stage the submodule pointer update:

cd ../..
git add vendor/libfoo
git commit -m "Advance libfoo submodule"

This is the correct flow. A submodule commit lives in the submodule repository, and the parent repository stores only the referenced submodule commit.

Discard the changes if they are accidental

If the tracked modifications inside the submodule should be thrown away:

cd vendor/libfoo
git restore .

If the untracked files should also be removed:

git clean -fd

Then return to the parent repository and run git status again. The submodule entry should now be clean.

If you want to reset the submodule completely to the commit recorded by the parent repository:

cd ../..
git submodule update --checkout vendor/libfoo

That is a stronger reset and is useful when the submodule drifted away from the recorded commit.

Use .gitignore for generated files

Sometimes the problem is not meaningful changes, but generated files inside the submodule such as build output, logs, or local editor files.

In that case, add appropriate ignore rules inside the submodule repository, not just in the parent repository:

1cd vendor/libfoo
2printf "build/\n*.log\n" >> .gitignore
3git add .gitignore
4git commit -m "Ignore generated files"

If the files are only local clutter and should never be committed, this is often the cleanest long-term fix.

Do not confuse submodule state with ordinary file state

If you run git status in a normal repository without submodules, Git usually reports modified and untracked files separately. The combined wording with parentheses is the clue that you are looking at a submodule entry.

That distinction matters because parent-level commands do not edit the submodule's internal history for you.

Common Pitfalls

The most common mistake is trying to fix the message only from the parent repository. If the path is a submodule, you need to inspect and clean up the Git state inside that submodule.

Another issue is committing the parent repository without committing the intended submodule changes first. That leaves the submodule pointer unchanged and loses the work you thought you had recorded.

People also run git clean -fd too quickly and delete untracked files they actually needed. Always check git status before removing anything.

Finally, if the untracked files are just generated artifacts, do not keep cleaning them manually forever. Add proper ignore rules in the submodule so the problem stays fixed.

Summary

• The (modified content, untracked content) message usually refers to a dirty submodule.
• Enter the submodule and run git status to see the actual files involved.
• Commit intentional work inside the submodule first, then commit the updated submodule pointer in the parent repo.
• Use git restore, git clean -fd, or git submodule update --checkout when you want to discard changes.
• Add .gitignore rules inside the submodule for generated files so the state does not keep returning.