If you open a file from a PR that contains an unsupported file type, it automatically opens your browser and navigates to the GitHub website and shows the preview. This is quite jarring and we should provide a better experience by showing a message and giving the user an option to preview on the web.
Repro steps
Expected
Updated the title, since there are other situations where we open the file on GitHub that we should explain, for example when it's too large. The GitHub API doesn't actually return a reason for why the patch isn't included, so we can either try to infer it or have a more generic message
Yeah I 100% agree on this. It definitely breaks my flow when doing a peer review in VSCode to unexpectedly have my browser open when clicking on the next file in the directory. In my case it was purely a renamed file - I see no reason why it can't just be shown in VSCode, or at the very least - a message saying something along the lines of This has solely been renamed and is accordingly not available here. Do you wish to view it on GitHub?
Unsupported types are one thing, but for a file that is too large (or doesn't have the patch included), can't you just get the whole contents of the file at that version to provide the diff?
Hi,
I'm commenting on this because I don't where to put this otherwise.
I understand that you're facing a limitation from github that won't let you fetch all the file content but here are some comments :
Anyway thanks for the hard work, really hope that you'll find some actual solution to this diff size problem.
Best regards
@Maskime Thanks for your feedback! This sounds similar to https://github.com/microsoft/vscode-pull-request-github/issues/1160.
I've previously reached out to GitHub to try to clarify what the exact circumstances are for patches not being returned and am still waiting for a response. This is definitely a pain point! With some refactoring we may be able to handle this by just making additional network calls when trying to open the diff to resolve the whole file contents of both sides instead of working with a patch.
Most helpful comment
Updated the title, since there are other situations where we open the file on GitHub that we should explain, for example when it's too large. The GitHub API doesn't actually return a reason for why the patch isn't included, so we can either try to infer it or have a more generic message