Stash, Worktrees, Temporary Work, and Parallel Development Contexts: Diagnostics, Failure Modes, Security, and Performance

1. Diagnostic sequence for context-switching failures

1. Preserve evidence: current path, branch/OID, status, stash list/OIDs, and worktree list.
2. Inspect status, refs, history, and config.
3. Identify the affected layer: current worktree/index, stash ref/reflog, shared branch ref, linked-worktree metadata, or external tool context.
4. Choose the least destructive correction.
5. Verify that no work remains hidden before dropping stashes or pruning/removing worktree state.

pwd
git rev-parse --show-toplevel
git status --short --branch
git rev-parse HEAD
git stash list
git worktree list --porcelain
git branch -vv

2. Failure mode — “I stashed everything,” but the untracked file is still here

Create one tracked modification and one untracked file, then run a default stash:

git status --short
git stash push -m "default stash demonstration"
git status --short

If the untracked path remains, Git is behaving correctly: default stash scope does not include it. Repair by deciding what that file is:

• If it is important temporary work, use git stash push -u -m "..." after restoring/applying the tracked context as needed.
• If it belongs in durable history, stage/commit it on the appropriate branch.
• If it is disposable output, inspect and remove it deliberately—do not assume stash is a cleanup command.

3. Intentionally broken example — pop conflicts but the stash survives

A branch changed the same line after the stash was created:

git stash pop stash@{0}

Typical output contains lines conceptually like:

Auto-merging service.conf
CONFLICT (content): Merge conflict in service.conf
...
The stash entry is kept in case you need it again.

Interpretation: Git attempted a three-way application; the file cannot be combined automatically; the index now contains conflict stages; and because application failed, the stash ref/reflog entry remains. Inspect:

git status
git diff
git stash list
git stash show -p stash@{0}

Resolve and stage deliberately, then verify the result. Only when the recovered content is safe should you run git stash drop stash@{0}. If current history has diverged substantially, abort the conflicted path state and consider git stash branch from the stash's original base.

4. Intentionally broken example — branch already active in another worktree

git worktree add ../second feature/metrics

Git refuses when feature/metrics is already checked out elsewhere. The failure protects the branch ref. Diagnose:

git worktree list --porcelain
git branch -vv
git -C ../feature-wt status --short --branch

The least destructive repair is usually to use the existing feature worktree, switch that worktree away after making it safe, or remove the worktree when finished. Do not reach for force just to suppress a useful ownership warning.

5. Failure mode — deleting the worktree directory manually leaves administrative metadata

In a disposable lab, suppose ../review-wt was deleted with the file manager instead of git worktree remove. The common repository can still remember the missing path.

git worktree list --porcelain
git worktree prune --dry-run --expire=now

If the directory is genuinely gone and no recovery is needed, prune the stale metadata:

git worktree prune -v --expire=now
git worktree list --porcelain

If the directory was moved and still exists, do not prune first; reconnect it with git worktree repair.

6. Failure mode — stash becomes a months-old “backup”

A stash is local state and can be dropped/cleared; once unreachable it is subject to normal object-retention/pruning behavior. Recovery after accidental drop is best-effort, not a service-level guarantee. If git stash list looks like a backlog, convert valuable work into branches/commits and delete only entries that have been verified unnecessary.

7. Failure mode — running the right tool in the wrong worktree

During a hotfix, two terminals can look almost identical while pointing at different branches/OIDs. Before any deployment, migration, version bump, signing, or release command:

pwd
git rev-parse --show-toplevel
git branch --show-current
git rev-parse HEAD
git status --short --branch
git worktree list

A production script can make these preconditions executable: require the expected absolute repository path, branch policy, clean status, and exact candidate OID before proceeding. The risk is operational context, not only Git syntax.

8. Security where worktree sharing matters

• Linked worktrees share the object database. Historical secret-bearing objects are visible from all of them; worktrees are not security sandboxes.
• Repository config is shared by default, so do not store privileged tokens there to “make only the hotfix worktree work.”
• Untracked credentials in one worktree are not automatically copied to another, but tools can still read external home-directory credentials unless isolated by the runtime.
• For untrusted CI code, prefer a stronger isolated workspace rather than relying on worktrees as a security boundary.

9. Performance tradeoffs that actually follow from the model

Worktrees save object-download and object-storage duplication, which can be valuable for large repositories and local parallel testing. They still duplicate checked-out files and often duplicate build outputs. Concurrent operations also share repository refs/object maintenance. Use worktrees for controlled parallelism, not as an unlimited job sandbox.

10. Red-zone commands and actions

11. Symptom → evidence → narrow correction

12. Knowledge check

13. Summary

Hidden-state failures are diagnosable when you inspect both dimensions: stash entries and worktree registrations. Keep the stash after conflicts, respect branch ownership, repair versus prune based on whether a directory still exists, and make operational tools assert the intended worktree/OID before acting.

Authoritative references

• git-stash
• git-worktree
• git-fsck