savetheclocktower
commented
5 days ago After some further tests, I can confirm that VS Code's behavior here matches what it does even outside the presence of a repository. If I have a file open in VS Code, and I delete the underlying file on disk, VS Code reacts exactly as documented above; it recognizes the “deleted” state of the file and indicates it with the strike-through and the red status color.
We ourselves could have such a state for all files. Aside from cosmetics, the major difference in VS Code is that you can close the editor of a deleted tab without an “are you sure?” confirmation; I suppose they feel like the red text and the strike-through are enough of a warning. (That confirmation will still happen, though, if the TextEditor was in a dirty state when the file was deleted.)
This would have to be a core change, but it's at least possible that this wouldn't be painful.
Have you checked for existing feature requests?
Summary
I don't know how feasible this is, but I'm going to throw it out here.
foo.jsexists on branchold, but not on branchnew.old. You openfoo.jsin order to make a change. You commit the change. You leavefoo.jsopen in your workspace.new.What Pulsar does in this situation is what it would always do if it detects that a
TextEditor’s backing file has suddenly disappeared: keep theTextEditoropen, but adjust its status to be “unsaved.” That's often the right move — you want an “are you sure?” dialog if you try to close the editor, and you want the indication in the tab bar that the item is not committed to disk.But in a version-control scenario, it's not what I want.
Let me try to turn this into a feature request:
If I were more diligent, I could have avoided the situation in my example by closing the
foo.jstab in my workspace before switching branches. So could thegithubpackage take care of that automatically?oldto branchnew.TextEditorin my workspace and ask these questions:new? (If so, ignore it.)old? (If so, ignore it; this is a bit paranoid, since Git would forbid the user from switching branches in this scenario, but it's good to be cautious.)TextEditorworkspace items that meet all the above criteria.What benefits does this feature provide?
Managing the number of open tabs is hard enough, even with zentabs. Any logic that can safely prune my list of open tabs without my intervention is a plus.
It doesn't necessarily have to be default behavior, either; I'd be fine with opting into this.
Any alternatives?
It's possible that the APIs exist for this to be its own package instead of something built into the
githubpackage. I'm only suggesting it for that package because I'm pretty sure it would be able to do this with its current libraries… but maybe it's something that any package could do.I notice that the
GitRepositoryclass is a bit short on event subscriptions; I would've expected a way to register a callback on a branch change, but maybe that wouldn't be too hard to add to core.Other examples:
VS Code, in this scenario, keeps the editor open, but marks the file as “deleted”:
Even though this file has an open editor, VS Code correctly recognizes that it would not be destructive to close the tab at this point, and it will not ask me to confirm when I close this tab.
If I were to edit the buffer, the tab would change to add a “dirty” indicator, and will now show a confirmation dialog if I try to close the tab:
And if I save the open buffer while it's in the “deleted” state — whether I made changes or not — it commits the file to disk, abandons this “deleted” status, and correctly marks it as a new, untracked file in this branch:
I'm fine with this behavior, especially as a medium-term goal, but I'd also be OK with VS Code just closing those tabs — if it knows enough to mark them as “deleted,” it knows enough to close them automatically for me. (There might be a setting for that; I haven't looked.)
But I know that's something that would definitely need to change in core, so I'm wondering if we can do the simpler thing in the short term.