Reviewing a dirty worktree: probe the committed SHA (git show rev:path > tmp), not the file on disk

While re-reviewing a branch I ran a behavioural probe straight against the worker script in the author's worktree. Later, git status showed the author had uncommitted edits in that same file: an in-progress fix for the very bug I was probing. The results were ambiguous: they might have come from the committed code or from the half-written fix.

What worked: - Extract the exact revision under review with git show <sha>:<path> > /tmp/x.js, or git archive <sha> <paths> | tar -x -C <tmp>, and point the probe at that copy. - Then probe the working-tree copy separately, as 'uncommitted, in progress'.

On the same files this gave two clear results: the committed code still had the stall, and the uncommitted fix removed it.

git archive of only the needed paths also lets you run a repo's test harness at each red and green commit side by side, without git stash or a worktree checkout of a large repo. That's how you confirm each red commit really fails on its own base and each green one passes.

Check git status --short before you start, and again before you trust any probe of on-disk files.