Git stash left a new file behind: inspect untracked files before restoring

By ON Lab · Sources checked November 8, 2026

A default git stash does not include untracked files. A successful stash message therefore does not prove that a new file was saved. Inspect the working tree and the selected stash separately; when intentionally saving new files, use the documented include-untracked option and verify the result before removing any other copy.

Why a menu selection can mislead

A reader issue describes selecting untracked files in an editor's source-control view and expecting a stash menu action to save them. The later investigation attributed that context-menu command to an extension, not the editor's built-in Git implementation. That history supports a specific lesson: identify the command provider and actual operation instead of assuming every menu labelled Stash has identical behavior.

This guide checks command-line Git behavior. It does not claim that the old extension problem persists today or that every missing file can be recovered from a stash. If a file was never saved in a commit, stash, backup, or editor history, these commands cannot manufacture a historical copy.

Inventory the files before saving a stash

git status --short
git diff
git diff --cached

In short status output, an untracked path appears with two question marks. Staged and unstaged changes are different states; inspect both diffs when deciding what to save. A file being visible in the editor is not proof it belongs to either diff.

Ignored files are another category. The include-untracked option includes untracked files, while all also includes ignored files. Broadening to all can collect large generated content or local material you did not intend to preserve in repository storage. Review those paths instead of using the broadest option as a routine repair.

What we observed in a local repository

Our example repository had a committed tracked.txt, a later edit to that file, and a new notes.txt. A default stash saved the tracked edit and restored tracked.txt to the commit, while notes.txt remained in the working tree. We then applied the saved entry, leaving the stash itself available.

Next we created a stash with include-untracked. Both the tracked edit and the new notes file were saved; notes.txt no longer existed in the working tree until we applied that entry. The restored contents matched both original edits. The stash list still contained the entry because apply does not drop it.

These were disposable local files. We did not test the reader's editor extension, a conflicted application, ignored files, a remote backup, or recovery after a stash was dropped.

Create and inspect an intentionally broader stash

If the inventory shows that the new files should be included, save a descriptive entry and read it back:

git stash push --include-untracked -m "work before branch switch"
git status --short
git stash list
git stash show --include-untracked --name-only 'stash@{0}'

The quoted stash reference avoids shell-specific interpretation of its braces. Confirm which entry you mean before using it: creating another stash changes the numbering. The newest entry in a later terminal session may not be the one you originally inspected.

The include-untracked option on show matters too. A summary that omits untracked content can make an existing saved file look absent. First inspect the correct entry with the appropriate display option rather than immediately declaring data loss or repeatedly creating new stashes.

Restore while keeping the saved entry available

git stash apply 'stash@{0}'
git status --short
git diff
git stash list

Apply restores the selected state without removing the entry. Pop combines application with removing the saved entry on successful application. Keeping the entry while inspecting the result makes it easier to separate restore success from cleanup, though a stash remains local repository state rather than an independent backup.

If you need the saved index state as well, the documented index option attempts that restoration. It can fail when conflicts prevent reinstating the index. Do not infer that an exit status of zero from an earlier stash command proves that a later application restored staging exactly as before.

If a file already exists or a conflict occurs

Read the complete error before changing the destination. Applying on a different commit or onto an existing file can conflict. Preserve useful destination contents and inspect the selected stash's paths; do not delete a file merely to make the command stop complaining.

After applying, open the actual files and run the project's relevant checks. If application failed, keep the stash and record what was restored and what remains unresolved. Avoid clear or drop while still investigating. This guide does not recommend forcing a destructive reset as a recovery step.

Completion is a content check

A trustworthy result identifies the exact entry, verifies the expected tracked and new files, confirms their contents, and preserves a recovery copy until that inspection is complete. A menu notification or stash count is only evidence that an operation ran.

If your problem is an ignored file that is still tracked, use the index and ignore-rule check. Changing an ignore rule does not decide which files an earlier stash captured.

Checked November 8, 2026. Default stash, include-untracked, show, apply, and retained-entry behavior were executed locally. Extension UI, ignored-file inclusion, conflicts, and deleted-entry recovery were not reproduced.