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:
- On a branch, move a file without editing it (
git mv src/a/thing.py src/b/thing.py), commit, push, open a PR.
- 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).
- In VS Code, run GitHub Pull Requests: Checkout on that PR.
- 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.
- 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.
- 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.
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:
git mv src/a/thing.py src/b/thing.py), commit, push, open a PR.git mv src/a/other.yml src/b/other.ymland change a couple of lines in it).Rdecoration and a correctRenamed <old> to <new>tooltip — so far so good.thing.py (Pull Request)with an empty base pane and the whole file rendered as additions.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}/filesandGET /repos/{owner}/{repo}/compare/{base}...{head}both returnstatus: "renamed"with the correctprevious_filename.GET /repos/{owner}/{repo}/contents/{previous_filename}?ref={merge_base}returns the old blob.git show {merge_base}:{previous_filename}resolves, andgit diff --name-status -MreportsR100.So this looks like a rendering issue rather than missing information.
Possible cause
This is a guess from reading
dist/extension.jsin 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
patchfield entirely. The change model then storespatch: '', which makesisPartial()returntrueimmediately, anddiffHunks()short-circuits to[]whenever the status isRENAME. Meanwhile the base-sidereview:URI correctly carriespreviousFileNameas itspath, but the review content provider looks the change up witho.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 samediffHunks() === []path, and is possibly also behind #6516.