Renamed file with no content changes is shown as a 100% new file in the PR diff

[paarriagadap]

Written by Claude Opus 5 — Pablo Arriagada (@paarriagadap) at the wheel.

• Extension version: 0.162.0
• VSCode Version: 1.134.0
• OS: macOS 26.5.2 (arm64)
• Repository Clone Configuration: single repository (PR branch in the same repo, not a fork)
• GitHub Product: GitHub.com

When a pull request moves a file to a different folder without changing its contents, the "Changes In Pull Request" tree opens the file as a 100% new file — empty left-hand pane, every line marked as added — instead of showing it as a rename with no content changes, the way github.com does.

Renames that also change content are fine. The problem is specific to content-identical renames.

Steps to Reproduce:

1. On a branch, move a file without editing it (git mv src/a/thing.py src/b/thing.py), commit, push, open a PR.
2. Also edit one other file in the same move so you have a rename-with-changes to compare against (e.g. git mv src/a/other.yml src/b/other.yml and change a couple of lines in it).
3. In VS Code, run GitHub Pull Requests: Checkout on that PR.
4. In the Changes In Pull Request tree, both files are listed once with the R decoration and a correct Renamed <old> to <new> tooltip — so far so good.
5. Click the content-identical one. The diff opens as thing.py (Pull Request) with an empty base pane and the whole file rendered as additions.
6. Click the rename-with-changes one. It diffs correctly: old path on the left, only the real line changes highlighted.

Expected: step 5 shows the file as renamed with no content changes (an empty diff), matching the Files-changed tab on github.com.

Notes

The data needed to render this correctly is available from every source I checked:

• GET /repos/{owner}/{repo}/pulls/{n}/files and GET /repos/{owner}/{repo}/compare/{base}...{head} both return status: "renamed" with the correct previous_filename.
• GET /repos/{owner}/{repo}/contents/{previous_filename}?ref={merge_base} returns the old blob.
• Locally, git show {merge_base}:{previous_filename} resolves, and git diff --name-status -M reports R100.

So this looks like a rendering issue rather than missing information.

Possible cause

This is a guess from reading dist/extension.js in 0.162.0, not from stepping through the extension — take it as a pointer, not a diagnosis.

For a content-identical rename GitHub omits the patch field entirely. The change model then stores patch: '', which makes isPartial() return true immediately, and diffHunks() short-circuits to [] whenever the status is RENAME. Meanwhile the base-side review: URI correctly carries previousFileName as its path, but the review content provider looks the change up with o.fileName === path — comparing against the new name — so the lookup never matches. The net effect is an empty base side, which the diff editor then renders as a whole-file addition.

A related symptom that may share the same root cause: line comments are unavailable on these files, with No commenting ranges: File was renamed with no diffs. in the log. That looks like the same diffHunks() === [] path, and is possibly also behind #6516.