git-stash-pop-pulls-unrelated-stashlisted

Diagnose and avoid `git stash pop` pulling in a stale stash from a different branch when the preceding `git stash` was a no-op. Use when: (1) `git stash` reports "No local changes to save" but you `git stash pop` anyway as a reflex; (2) `git stash pop` surfaces files you don't recognize, often with "both modified" merge conflicts in files unrelated to your current work; (3) `git status` after a stash pop shows changes in files from other features / other branches; (4) `git stash list` reveals stash entries from sibling worktrees or older branches. The stash stack is GLOBAL across branches and worktrees — it's LIFO and branch-agnostic. Pairing `git stash` / `git stash pop` defensively (e.g., before `git checkout -- file`) only works when the initial stash actually saved something; otherwise the pop reaches deeper into history. Save under user-wide skills.
wan-huiyan/agent-traffic-control · ★ 2 · Code & Development · score 79

Install: claude install-skill wan-huiyan/agent-traffic-control

# `git stash pop` pulls an unrelated stash when preceding `git stash` was a no-op ## Problem You defensively wrap a risky operation with `git stash` / ... / `git stash pop` to preserve in-progress work. The working tree is clean, so `git stash` prints **"No local changes to save"** and exits 0. Later, `git stash pop` pulls in modifications from a *different* branch's stash entry — sometimes months old, sometimes from another worktree, often producing merge conflicts in files you never touched in this session. ## Context / Trigger Conditions You'll see one or more of: - `git stash` immediately echoed **"No local changes to save"** - `git stash pop` runs without error and announces something like `On branch <X>: WIP on <other-branch>: <sha> <commit-msg-from-elsewhere>` - `git status` afterward shows: - Modified or unmerged files you didn't touch - `both modified: <path>` for paths from unrelated features - Filenames matching files on entirely different branches - `git stash list` shows entries like `stash@{0}: WIP on feature/sca-polish: ...` that reference branches you're not on ## Root Cause The stash stack is a **global, branch-agnostic, LIFO data structure**, shared across every worktree of the repo. `git stash pop` always pops `stash@{0}` — it doesn't care which branch the stash was created on. When `git stash` is a no-op (clean tree), nothing is pushed onto the stack, so a subsequent `git stash pop` reaches whatever was on top *before* this session — poten