Git Diff Shows Nothing? Check the Staged Snapshot

Check which two versions you are comparing#

Start with these read-only commands from the repository root:

1
git status --short
2
git diff
3
git diff --cached
4
git diff HEAD

The Git diff reference distinguishes these comparisons. --staged is a synonym for --cached.

The index is Git’s staging area. It is a stored snapshot, not a live reference to your editor buffer. Pro Git’s recording-changes chapter explains why editing a file after staging creates another unstaged change.

For one file, add an exact path after --:

1
git diff -- settings.txt
2
git diff --cached -- settings.txt
3
git diff HEAD -- settings.txt

These commands compare snapshots; they do not list every file on disk. Check git status --short for untracked paths too.

Read the two status columns#

For ordinary tracked files outside an unresolved merge, Git’s short status format uses the first column for the index and the second for the working tree:

1
M  settings.txt
2
 M settings.txt
3
MM settings.txt
4
?? notes.txt

These are separate possible results, not four entries for one working copy:

• M : the index differs from HEAD; no further working-file change is reported.
• M: the working file differs from the index; no staged modification is reported.
• MM: both comparisons report a modification. Inspect both diffs.
• ??: the file is untracked and does not appear in the normal tracked-file comparisons above.

An empty plain diff with M is expected: the staged snapshot and working file agree. With MM, an empty git diff HEAD can mean the working file has returned to the committed content while the index has not.

If the symptom is a tracked file appearing despite an ignore rule, use the gitignore tracking diagnostic instead. Ignore rules and diff comparison endpoints solve different problems.

Reproduce the empty HEAD comparison#

This disposable fixture was executed during article verification on October 3, 2026, using git version 2.54.0 (Apple Git-157) on macOS. It covers an ordinary text file in a repository with an existing commit. It does not test merge conflicts, submodules, sparse checkouts, or custom diff drivers.

Run the following in Bash, separately from your project. The final commit exists only in the temporary repository; no remote is configured.

1
set -eu
2
fixture_dir="$(mktemp -d)"
3
git init -q -b main "$fixture_dir"
4
cd "$fixture_dir"
5
git config user.name Fixture
6
git config user.email fixture@example.invalid
7
printf 'theme=light\n' > settings.txt
8
git add -- settings.txt
9
git -c commit.gpgsign=false commit -qm "Baseline"
10

11
printf 'theme=dark\n' > settings.txt
12
git add -- settings.txt
13
printf 'plain diff after add:\n'
14
git --no-pager diff -- settings.txt
15
printf 'cached diff after add:\n'
16
git --no-pager diff --cached -- settings.txt
17

18
printf 'theme=light\n' > settings.txt
19
printf 'status after reversing the working edit:\n'
20
git status --short
21
printf 'diff HEAD:\n'
22
git --no-pager diff HEAD -- settings.txt
23
printf 'cached diff:\n'
24
git --no-pager diff --cached -- settings.txt
25
printf 'unstaged diff:\n'
26
git --no-pager diff -- settings.txt
27
printf 'index contents:\n'
28
git show :settings.txt
29

30
git -c commit.gpgsign=false commit -qm "Commit the staged snapshot"
31
printf 'committed contents:\n'
32
git show HEAD:settings.txt
33
printf 'working contents:\n'
34
cat settings.txt
35
git status --short
36
printf 'fixture: %s\n' "$fixture_dir"

After the first git add, plain diff printed nothing and cached diff showed light changing to dark. After the working file was manually changed back, the observed state was:

Status printed MM settings.txt. The HEAD comparison printed nothing, while cached diff contained:

1
theme=light
2
theme=dark

The unstaged diff showed the reverse:

1
theme=dark
2
theme=light

The two changes cancel when comparing the endpoints, but the staged snapshot still differs. The final ordinary commit recorded theme=dark; the file on disk remained theme=light, and status then printed M settings.txt. An empty HEAD diff before committing had not established that the next commit would be empty.

Review the snapshot you intend to commit#

For an ordinary commit without path arguments or -a, review the whole staged diff, then inspect the intended paths:

1
git diff --cached --name-status
2
git diff --cached
3
git show :settings.txt

If the staged version is the one you want, further edits can remain unstaged. If the current working version is the one you want, stage that exact file again and inspect the result:

1
git add -- settings.txt
2
git diff --cached -- settings.txt
3
git status --short

In the fixture’s pre-commit state, staging theme=light again would make the index match HEAD and remove that file’s pending change. A separate verification run repeated the fixture up to its pre-commit state, staged the working file again, and confirmed an empty cached diff and clean status. The fixture above instead demonstrates committing the earlier staged version.

Git’s commit reference describes other commit forms that change the selection: -a stages modifications and deletions of tracked files, while explicit path arguments select those working-tree contents. Therefore, the cached diff is a preview of the ordinary reviewed-index commit, not every possible commit command.

Use git diff --cached to inspect the next staged snapshot and git diff to inspect edits after staging. Keep git diff HEAD for the net working-file comparison; an empty result there is insufficient evidence that nothing is staged.

References:

• Git diff reference
• Git status short format
• Git commit reference
• Pro Git: Recording Changes to the Repository