The operation would stomp uncommitted changes in the affected files. Git refuses rather than guessing. Choose deliberately: stash (keep them), commit (keep them properly), or discard (lose them) — the three moves cover every case.
A checkout/merge needs to change files you've modified but not committed. Git protects them by refusing. git status shows exactly which files are the conflict.
Files you never touched appear modified (CRLF rewrites, filters, permission masks): the same refusal fires on files with no real edits. git diff reveals phantom-vs-real changes immediately.
git status --short ; git diff # phantom changes (you never edited) -> filter/line-ending issue, not stash materialgit stash push -m 'before merge' && git pull && git stash pop # pop after the operation completesgit add -A && git commit -m 'wip' && git pull --rebasegit checkout -- <files> # or restore: git restore <files> ; whole-tree: git reset --hard HEAD (drops ALL uncommitted work)stash is the safe universal: it survives the operation, pops afterward, and conflicts (if any) resolve like merge conflicts. It never loses work by itself. git reset --hard answers this error but answers several OTHER questions destructively too — scope it, don't reflex it.
It doesn't — the refusal lists only files the operation would rewrite. If the list surprises you, check git diff for phantom modifications (line endings, filters) — those need a renormalize fix, not a stash.
It becomes a normal merge conflict in your working tree: resolve, add, and git stash drop. The stash itself stays intact until you drop it — nothing is lost by the conflict.
Our most-documented failures, packaged as ready-to-ship starter kits: Docker, Kubernetes, and Terraform.
Browse the template store →One-time. Yours to modify. Instant download from the NinjaOps template store.