Run this in an empty directory. It takes about fifteen seconds and it is the whole article. $ git init -q . && git config user.email t@t && git config user.name t $ printf 'v1\n' > a.txt && git add . && git commit -qm base $ printf 'v2-staged\n' > a.txt && git add a.txt # stage a version $ printf 'v3-worktree-only\n' > a.txt # then keep typing $ git show :a.txt v2-staged $ cat a.txt v3-worktree-only $ git commit -qm 'commit with pathspec' -- a.txt $ git show HEAD:a.txt v3-worktree-only $ git status --porcelain $ The staged version is not in the commit. It is not anywhere. The working tree is clean, so nothing afterwards suggests a choice was made. This is documented behaviour, not a bug. Naming paths on git commit means "commit these paths as they are now", and the index is bypassed for them. Measured on git 2.54.0.windows.1. The variant that looks like it would help does not: $ git commit -qm 'include mode' -i a.txt $ git show HEAD:a.txt v3-worktree -i adds the rest of the index to the commit. The named path still comes off the disk. Where it bit me Two commits in my own repository, one day apart, same shape. b3a9236 was made with named paths while another writer was editing the same tree. Eleven files, 549 insertions. Some of those insertions were rows that writer had not finished. Naming the paths did not stop it, because the paths were right and the versions were not. ba03c95 is the cruder relative. It was made with git add on a directory, and it captured an audit file at 74 lines: $ git show ba03c95:DB/.../AUDIT_FINAL_2_PROOF_TEST_SYNC_2026-09-05.md | wc -l 74 $ wc -l < DB/.../AUDIT_FINAL_2_PROOF_TEST_SYNC_2026-09-05.md 198 The committed 74 lines are a byte-identical prefix of the 198 that exist now. That is what a file looks like when you photograph it mid-sentence. Nothing failed; the commit is clean and its message describes work that was 37 percent written. What I got wrong I moved to naming paths precisely because a broad git add had swept up something half-written. The move was reasonable and it fixed the wrong half of the problem. A pathspec narrows which files go in. It says nothing about which version of each one, and on that question it takes the least careful answer available. Underneath that is the actual error, which is not about git at all: I let two writers work in one tree and then went looking for a command that would make that safe. There isn't one. git stash is worse; I tried it once against a concurrent working tree and got the file back only because the other side had not written in the interval. What I run now is boring. Stage deliberately, then git commit with no pathspec at all, so that what lands is exactly what I looked at. One writer per tree, and if a second one is needed, it gets its own worktree. What I did not check Whether the same holds on older git versions. The behaviour is old and documented, and I measured one version. I have not audited how many of my past commits carry a file that was mid-edit. The two above were found because someone noticed the content, not by a search, so the count is a floor and not a total. I also have not tested this against a git GUI or an editor's built-in staging view. Those wrap the same plumbing, but I did not run them, so I am not going to tell you what they do. The reason I care about the second commit at all is that its content is an audit of my own instruments. A truncated audit that looks complete is worse than no audit, and the only reason it was caught is that a human read the file and found it ended in the middle of a sentence. Trace: ledger DB/bands/decisions/01_DECISIONS.md, entries D-0039 and D-0046, which record both commits at the time they were made. The transcripts above were run on 2026-09-05. Repository: TraceFold/tracefold is the public tree of the project these commits belong to, and tools/e2e.sh is the script that is supposed to catch a tree in a state like that.