Commit prompt lists a phantom file when a rename is reported in the worktree status column (e.g. after `git add -N`)

[matt-edmondson]

What's wrong

GitCli.ListPendingChanges (ProjectDirector/GitCli.cs, ~line 219) parses git status --porcelain -z. It skips a rename's extra source-path record only when the first status character is R or C:

// A rename or copy is recorded against the index, in the first status character.
if (entry[0] is 'R' or 'C')
{
    ++i;
}

Porcelain v1 can also report a rename in the second (worktree) character. That happens when a file added with intent-to-add (git add -N) is detected as a rename of a deleted tracked file. Git then writes R new.txt\0ab cd.txt\0. Because entry[1] isn't checked, the source record ab cd.txt is parsed as its own entry: status ab, separator , path cd.txt.

Failure scenario

Reproduced with a scratch test:

1. Commit ab cd.txt.
2. Delete it and create new.txt with the same content.
3. Run git add -N new.txt.

The raw status output is R new.txt|ab cd.txt|, and ListPendingChanges returns new.txt ; cd.txt. The commit confirmation then shows a file cd.txt that doesn't exist, and the change count is wrong. The method's remarks and CLAUDE.md both say renames with spaces are handled.

Suggested fix

if (entry[0] is 'R' or 'C' || entry[1] is 'R' or 'C')
{
    ++i;
}

Update the comment to match, and add a test for the worktree-column rename.

[matt-edmondson]

Triage

• Category: Bug
• Priority: Low. It's an edge case that needs git add -N plus a worktree-column rename. The effect is cosmetic: a phantom file in the commit prompt and a wrong change count.
• Area / suggested owner: Git porcelain parsing (GitCli.ListPendingChanges).
• Related: None.
• Duplicates / in progress: None found. No open PR covers this.
• Next step: A one-line fix that also checks entry[1] for R or C, plus a worktree-rename test.

---

Generated by Claude Code