Introduction

Diffing your current working tree against a stash is useful when you want to see how your in-progress changes compare with work you parked earlier. Git can compare your current state directly to any stash entry, but the exact command depends on whether you want a full patch, a file-specific diff, or only a quick summary.

The safest workflow is to identify the correct stash first, inspect it, and only then decide whether to apply or drop it. That avoids avoidable conflicts and wrong-reference mistakes.

Start by Listing the Stashes

Always check which stash entry you actually want:

git stash list

Typical output looks like this:

stash@{0}: WIP on feature/search: 1a2b3c4 add debounce
stash@{1}: WIP on feature/search: 8d9e0f1 fix tests

Most of the time, stash@{0} is the most recent entry, but you should not assume it blindly if there are several.

Diff the Current Working Tree Against a Stash

The direct command is:

git diff stash@{0}

This compares your current tracked file state against the stash snapshot. It is the normal answer when the question is simply "how is my current work different from that stash?"

If you want to limit the diff to one path:

git diff stash@{0} -- src/search.ts

That is useful when only one file or directory matters.

Use git stash show for a Quick Look

Sometimes you do not need a full comparison to the current working tree. You only want to inspect what the stash contains:

git stash show stash@{0}
git stash show -p stash@{0}

git stash show gives a summary, while -p prints the full patch. This is often faster than a broad diff if your goal is just to review the stash contents before deciding what to do next.

Compare Against HEAD Instead of the Working Tree

Be clear about what you are comparing. These commands answer different questions:

git diff stash@{0}
git diff HEAD stash@{0}
git diff stash@{0} HEAD

• 'git diff stash@{0} compares the stash to your current tracked state'
• 'git diff HEAD stash@{0} compares the current commit to the stash'
• reversing the order reverses the add-remove direction in the patch

If the diff signs look backwards, check the argument order first.

A Practical Workflow

A safe sequence usually looks like this:

1git status
2git stash list
3git stash show -p stash@{0}
4git diff stash@{0}

If the stash still matters and you want to test it against your current tree without deleting it:

git stash apply stash@{0}

That lets you inspect conflicts and results before deciding whether to keep or drop the stash entry.

Useful Diff Options

For large changes, the default patch may be noisy. These variants are often helpful:

git diff --name-only stash@{0}
git diff --stat stash@{0}
git diff --word-diff stash@{0}

Those give you a path-only view, a change summary, or a word-level patch depending on what kind of review you need.

Know That a Stash Is More Than "Loose Changes"

A stash can include:

• tracked working tree changes
• staged changes
• sometimes untracked files, depending on how it was created

That is one reason stash diffs can look more complex than expected. A stash is not just "one text blob of changes." It is a stored snapshot of state.

Common Pitfalls

The biggest mistake is diffing the wrong stash entry because git stash list was skipped. If several stashes exist, stash@{0} might not be the one you had in mind.

Another common issue is misreading diff direction. If added lines appear as deletions, reverse the argument order and inspect again.

Developers also sometimes apply a stash before reviewing it, which can create avoidable conflicts in a dirty working tree.

Finally, remember that stashes are not permanent history. If you drop or clear them, the references are gone. Inspect first, then clean up.

Summary

• Use git stash list first so you diff the correct stash entry.
• Use git diff stash@{n} to compare your current tracked state against a stash.
• Use git stash show -p stash@{n} when you only want to inspect the stash itself.
• Narrow the diff with file paths or summary flags when the patch is large.
• Check diff direction carefully before interpreting additions and deletions.