git stash push -u does not put ignored files into the stash. If an agent has changed tracked code, created a new note, and written an ignored local configuration file, those files do not all receive the same treatment. Switching to -a changes that boundary: it can put the ignored file’s contents into Git’s local object database.
That is a choice about what you are storing, not just a more complete cleanup command. Before asking a coding assistant to “stash everything,” decide which files should enter Git and which need separate, protected storage.
Three modes, three outcomes
We tested Git 2.50.1 (Apple Git-155) with Python 3.14.3 on macOS on November 1, 2026. Each mode ran in its own disposable repository with no remote. All contents were synthetic.
Each repository started with a tracked file containing base, an index version containing staged, and a later working-copy version containing working. We also created an ordinary untracked notes.txt and an ignored .env.local containing a dummy value.
| Fixture operation | Tracked working file afterward | Untracked note afterward | Ignored configuration afterward |
|---|---|---|---|
git stash push | Reset to base | Still on disk | Still on disk |
git stash push -u | Reset to base | Removed into stash | Still on disk |
git stash push -a | Reset to base | Removed into stash | Removed into stash |
The official Git stash manual distinguishes including untracked files from including ignored files. These observations are not a test of an editor’s stash button, an agent’s implementation, or cloud backup behavior.
A remaining ignored file is not a failed stash. It is outside the selected operation’s scope. Conversely, a file disappearing after -a does not prove it was securely erased.
The secret-storage consequence of -a
In the -a fixture, the dummy .env.local contents were readable from the stash’s third-parent snapshot. This check was confined to dummy data; the downloadable script prints only the result, not the stored value.
This was a local repository with no remote, so the test does not establish that anything was published. But ignore rules did not prevent Git from storing the contents. A later copy of the repository’s Git data could include them. Ignore rules are not encryption or an access-control boundary.
Do not use -a as a blanket recommendation for real credentials. Decide whether those files should stay outside Git first. Dropping a stash is not a secure-erasure guarantee either; this experiment does not test object pruning or recovery after deletion.
The Gitignore boundary guide explains tracked files, ignore rules, and history. This article adds a different decision: whether a temporary local snapshot should contain an ignored file at all.
Applying is not the same as consuming
In the isolated -a case, git stash apply --index restored all four states we checked: the staged tracked version, its later working-copy version, the untracked note, and the ignored dummy configuration. The stash reference remained afterward.
This was a clean fixture with no conflicting edits or existing destination files. It does not establish that applying a stash to a changed branch will succeed. --index attempts to reinstate index state; conflicts can prevent that. Keep the stash until you have reviewed the restored files.
Restoring work is also separate from reviewing a commit. The commit snapshot experiment shows why reviewing one snapshot and committing another is a different failure mode.
A review checklist before an agent stashes work
Start with filenames, not secret values:
git status --short --untracked-files=all
git diff --name-only
git diff --cached --name-only
git ls-files --others --exclude-standard
git ls-files --others --ignored --exclude-standardThe ignored list can include large dependency and cache directories. It is an inventory to review, not an instruction to archive every entry. Filenames can themselves be sensitive; do not paste them indiscriminately into public issues.
Give the agent an explicit boundary:
List tracked, ordinary untracked, and ignored paths separately. Do not stash or delete files yet. Identify which local-only files would remain outside a normal stash or a stash with
-u. Do not read or print secret contents. Confirm the intended storage boundary before putting ignored files into Git.
After an authorized stash operation, check its identity, remaining paths, and restoration behavior. An empty ordinary status view is not a complete inventory of ignored files. A stash inside the same repository is not an independent backup against losing that repository.
Run the experiment without touching your project
Download the standalone synthetic stash lab, inspect it, and run it with an existing Python 3 installation and macOS Git:
python3 git-stash-boundaries-lab.pyIt accepts no repository path, creates three temporary repositories, and cleans up only its temporary directory. It uses /usr/bin/git, isolates personal Git configuration, and points hooks to an empty directory for its fixture commands only. It does not disable checks in your project, install dependencies, contact a remote, or read your real environment files.
Six checks cover the three mode outcomes, ignored data entering a stash object, index-aware restoration, and retention of the stash reference after apply. Passing them proves these fixture observations on the reported version. It does not prove encrypted storage, safe handling of real secrets, cross-platform behavior, or conflict-free restoration in your repository.
When this changes a tool-buying decision
The inventory and Git checks above are free. You do not need a paid secrets manager just to choose a stash mode.
A different requirement arises when several people need controlled access to credentials and access must be withdrawn when someone leaves. Evaluate that separately using the secrets-management offboarding checklist. A secret-sharing product is not a backup for arbitrary local files and does not change what git stash -a stores. This experiment does not measure any paid product’s superiority or purchase outcome.