Let us say, you are working with Visual Studio Code on a file f1.md in git branch-1 and then you switch to branch-2 that does not contain the file.
You get distracted because someone pinged you to ask you a question or you had to attend that mind-numbing meeting; two hours later you get back to Visual Studio Code.
Because you switched contexts, you forgot you switched branches and now you think you are on branch-1 and edit f1.md without looking at the top or which branch you are on because the "open editor" still shows it.
Let us say you have another interruption and this time you really make changes on a file f2.md in branch-2.
Sometime later, you do a git add -A and commit and push to branch-2. Now branch-2 has file f1.md which should never have been there.
Why does "Open Editors" remember the files being edited when I was on branch-1? This is somewhat dangerous. The "Open Editors" probably should remember the files open for a specific branch and not universally across all branches.
One can argue that we should stay away from git add -A as it adds both tracked and untracked files. But still, it seems reasonable to expect "Open Editors" to remember files specific to a branch and not display files edited in other branches purely from a UX point of view.
3
Answers
When you switch branches in Git, Visual Studio Code (VSC) retains the open editors (and the branch) because it assumes that you continue working on the files when you switch back to that branch.
"Open Editors" are not aware of the branch context and remember the open files of your last session. You need to check which branch are you on when you return to your computer/editor. In VSC, You can see the branch by checking the Git status in the bottom-left corner. Or by using
git branchorgit statusin the integrated terminal.Maybe also a question for the VS Code team at https://github.com/microsoft/vscode or https://github.com/microsoft/vscode-docs/issues?
I’m pretty sure this is a feature and/or by-design.
For one thing, git will not automatically stage unstaged changes before you switch to another branch. It will just keep the unstaged changes as-is in the working tree, or issue a warning and abort the operation.
On top of that, VS Code’s edit buffers are a level "higher" than the working tree. Changes in the editor do not get persisted to the filesystem until you actually invoke the "save" action.
Given that, I think it would be more generally disruptive and unexpected if VS Code were to automatically close all open editors upon a branch-switch / commit-checkout. And it would be an even bigger pain if one of the editors had unsaved changes- then the user would have to be prompted for whether or not to save those changes, and there could be multiple files with unsaved changes.
If you want to have what you’re looking for, you can:
My 2 cents regarding the way to use git:
I came to appreciate the separate stage and commit phases because it gives a rather natural step to review my changes.
IMHO expecting a
git add -A && git committo guess through all the hoops my mind went through is doomed to bring in bad/unwanted changes.I would suggest you always take time to review what you are about to commit.