I admit that it's a niche scenario, but I think that what "Open Changes" shows for not-yet-staged changes to files that have been detected as renamed in the index is incorrect, at least inconsistent with how changes to files in the index are shown that have not been renamed.

Steps to Reproduce:

1. Create an empty directory and initialize a git repository in it.

2. In that directory create two files file1.txtand file2.txt with identical content:

abc defg hijkl mnop qrst uvwxyz
defg hijkl mnop qrst uvwxyz abc
hijkl mnop qrst uvwxyz abc defg
mnop qrst uvwxyz abc defg hijkl
qrst uvwxy zabc defg hijkl mnop
uvwxyz abc defg hijkl mnop qrst

This exact content is somewhat important, as I've confirmed that it triggers git's "rename detection" (checked with git v2.14.1).

2. Stage and commit both files.
3. Duplicate the first line in both files.
4. Rename file2.txt to file2-renamed.txt.
5. "Stage All Changes":

6. Now Open Changes does the right thing for both files, that is, it shows the changes between HEAD and the staged version:

file1.txt:

file2-renamed.txt:

7. Duplicate the first line in both files once more, but don't stage these changes.

8. Now Open Changes still shows the right thing for file1.txt (in this case the changes between the staged version and the file in the working tree):

As the content of both files is identical both in the index and the working tree, I would have expected the exact same result for file2-renamed.txt, but now the left side is just empty instead of showing the staged version:

• VSCode Version: Code 1.16.1 (27492b6, 2017-09-14T16:26:20.018Z)
• OS Version: Linux x64 4.12.13-1-ARCH