What is the difference between git update-index --assume-unchanged and --skip-worktree?

## The shared mechanism Every entry in `.git/index` carries flag bits alongside its path, mode, blob id and cached stat data. `git update-index` is the plumbing command that edits those entries directly, and two of its flags set bits that make Git stop reporting working-tree changes for a path. Both are strictly local: the index is not a tracked object, so nothing about either bit is pushed, fetched, cloned or seen by anyone else. Inspect the current state with `git ls-files -v`. The tag letter in the first column tells you which bit is set: `S` marks a skip-worktree entry, and a lowercase tag letter means assume-unchanged. Clear them with `--no-assume-unchanged` and `--no-skip-worktree`. ## --assume-unchanged: a performance hint The documented purpose is filesystems where `lstat` is expensive. You promise not to modify the path, and in exchange Git is allowed to skip checking it, which can shave real time off `git status` in a huge tree. Because it is a promise rather than an instruction, Git reserves the right to ignore it. Any operation that needs to update the index for that path — a branch switch, a merge, a pull that touches the file — may clear the bit and replace the file with the committed content. There is no warning and no reflog entry for the working-tree copy, because your edits were never in the object database. That is the failure mode people hit: months of quiet success, then a routine pull silently overwrites their local settings. ## --skip-worktree: the index copy wins Here the statement is about authority rather than performance. The index entry is declared the truth for that path, so Git should not read the file and should avoid overwriting it. Git preserves the bit across index-updating operations and refuses some operations rather than clobbering a skipped file, which makes it noticeably stickier in practice than assume-unchanged. Its real design purpose is sparse checkout: paths outside your sparse pattern set stay in the index, marked skip-worktree, with no corresponding file on disk. That is why the flag is well maintained — it is load-bearing for a shipped feature rather than a corner in the plumbing. ## Why neither solves the local-config problem The question is nearly always asked because someone wants to edit a tracked configuration file without ever committing the change. Both bits appear to do it, and both are the wrong answer: - **Not shareable.** Each teammate must run the command by hand on every clone, and nothing reminds them. - **Lost silently.** A fresh clone, a new worktree, or anything that rebuilds the index starts without the bit. - **Dangerous in the other direction.** When upstream legitimately changes that file, you either miss the change or hit an obscure failure, and with assume-unchanged you can simply lose your edits. - **Actively deceptive.** Your local edits are invisible to `git status`, so a real change to that file will never be committed, and the divergence between what you run and what the repository says compounds over time. The answer an interviewer is listening for is structural: do not track the environment-specific file at all. Commit a `config.example` template, ignore the real path, and have the application or a setup script produce it. If a tracked file must vary per environment, that variation belongs in an environment variable or a layered configuration mechanism, not in a hidden index bit. The legitimate uses are narrow — assume-unchanged as a measured performance workaround on a pathologically slow filesystem, and skip-worktree as an implementation detail of sparse checkout — and both are best kept out of everyday developer workflow advice.