Opening revision of a renamed file is broken

[eamodio]

• Open a project in vscode
• Rename a checked (committed) in file from x.js to x.ts or similar
• Open the file in vscode
• Trigger the "Open file at revision..." command

Expected behaviour: be presented with a revision picker
Actual behaviour: "Unable to show commit history"

Nothing logged to the GitLens output

Originally posted by @mogelbrod in #708 (comment)

[eamodio]

@mogelbrod Can you please verify this fix in tomorrow's (v2023.12.12xx) pre-release edition of GitLens? Thank you so much!

You can switch to the pre-release edition of GitLens, by clicking on the "Switch to Pre-Release version of this extension" from the Extensions view.

[mogelbrod]

@eamodio I seem to be stuck on v2023.12.1104 no matter how many times I switch between pre-release and release version, even after reloading and restarting vscode 🙁

[mogelbrod]

v2023.12.1204 appears to have been released now 👍 After installing it I'm still seeing the same issue though, unfortunately. I can consistently repro it by opening a git repo, renaming any file, opening it in the vscode editor and triggering "Open Changes With Revision..."

[eamodio]

@mogelbrod wow sorry about that, I dunno what happened with this one, but this should be fixed for real in tomorrow's pre-release (v2023.12.13xx)

[mogelbrod]

Updated to v2023.12.1304 and unfortunately getting the same error. Also noticed that the Open file at revision... command doesn't even show up in the command palette - I've been triggering it via a hotkey all this time (gitlens.diffWithRevision). So I'm guessing the issue might be that the command itself technically doesn't support uncommitted files right now?

[eamodio]

Ah, if you haven't staged the rename that is "by-design" -- Git (and GitLens by proxy) doesn't do rename detection until the file is staged. Prior to staging, Git just sees things as a file that was deleted and a new file that was added. And that new file is untracked, and thus has no history.

There was an issue when you staged it as well (and it shows as a rename), but that is what should now be fixed.

[mogelbrod]

For consistency and to avoid confusion, could it make sense to still prompt for another file if the command is called with a file that is neither staged nor committed? It's a common use case for me to want to compare a renamed file with the one in history, and it will be kinda annoying to have to remember to first stage it temporarily just to do so (especially if I already have a busy staging area)