Git: Preserve open files list when switching branches

[fujitatakesh]

I suggest for saving file opening status each git branches. I think the each branches need different files on the branches. If I changed branches and close and open files every time. Next time if I changed branch again, next process is closing opening files and opening files needed to edit. And next time...

[topaztee]

any updates on ths?

[mbonaci]

Could this be done on the extension level?

[moriawan]

Is anyone working on this ?

[GargantulaKon]

I was wondering the same thing as I noticed that IntelliJ IDEA CE has that feature. I found it really useful. For now, I have to copy the relative path of every file to keep a list of opened files and then close the files. I then switch branches and then re-open files by searching for each of them.

I have also tried the workspaces feature to see if it saved the opened files, but alas it didn't.

[StephenGrable1]

This feature would be AMAZING

[jas-naz]

I have been hoping for a feature/extension that would do this for months now. It would be great as I jump around a lot and have lots of files. I thought Workspaces was the answer but it doesn't seem to function that way.

[webworthydesign]

I recently switched from IntelliJ to VSCode and this has become a big problem and will likely cause me to need to switch back. It's a shame, I'd really like to have this feature added as I'm definitely enjoying VSCode but at my job, we switch branches far too often to keep opening/closing tabs so much. :(

[chinapalace]

This is the feature I want most to be added to VS code

[mymikemiller]

This is something I'd really like too. I'd like to try my hand at implementing this feature. I have some questions for someone who knows the codebase better than I do.

• Would this be better implemented as an extension, or in VSCode's codebase itself?
• Where would be the proper place to store a map of branch names to open file paths such that they don't get checked into source control, but do persist across sessions? Where does VSCode store the list of open files that it restores when VSCode is closed and re-opened?
• What's the best way to detect when a user switches their branch? Is there a way to do it without polling? This feature ought to work when the branch is switched outside of VSCode (e.g. in an external terminal)

[jack27121]

Any news? At all?

[romines]

The Restore Editors extension helps with this issue a lot.

[netzpixel]

@romines That doesnt help too much. It has to be automatic not manual.

[DanHitt]

I would love to see this! Switching projects is very annoying.

[DanHitt]

Any news?

[mbrammer]

The only thing I am really missing in VS Code!

[kangzeroo]

This would be A+. In Atom there is a package called git-tabs.
https://atom.io/packages/git-tabs

[afalchi82]

Dear feature, we still miss you 🕯️

[bpartridge]

There may be a hard dependency on #15178 for this to be fully realized - I've done some research to try to unblock it but it'll definitely require some expansion of the extension API to be able to use internal services that describe the Groups of open editors. If this can be polled and modified reliably (and if we can open files into specific Groups), and Git can be polled as well, it could allow for some really interesting workflows!

[ilirhushi]

Check out this package: https://marketplace.visualstudio.com/items?itemName=eamodio.restore-editors

I found it very useful

[jcquinlan]

Just found https://github.com/gkotas/vscode-restore-git-branch-tabs as well. Haven't taken it for a full spin yet, but this seems to be the right idea.

[joFolta]

Here's the link to the extension
https://marketplace.visualstudio.com/items?itemName=gkotas.restore-git-branch-tabs
Seems to work!

[JorgeSivil]

As a user from PHPStorm forced to use VSCode for remote development, this is a major pain

[dreit-p]

I always remember this thread when I change my branches. It is essential functionality! In 5 days it will be 6 years of this issue. How will we celebrate it?

[adamc55]

Definitely a feature that is sorely needed.

[rob-apella]

+1

[sakalosj]

any update?

[starball5]

Related: #143794 and #98294

Related on Stack Overflow:

• In VS Code, Store a group of file tabs so that I can restore a specific environment in the future <- I wrote an answer to this one
• vscode, auto open/close editors on switching git branches
• Why does switching git branches in VS Code not switch "open editors"?

Related on r/vscode:

• https://www.reddit.com/r/vscode/comments/181hlvq/workspace_switch_on_branch_change/

[dreit-p]

@starball5, you asked on StOv to avoid noisy comments like “+1/bump”. If I understand correctly, the bot here will close the issue as inactive if people will stop to make a noise here. The issue must live :)

[starball5]

@dreit-p If it's received enough thumbs up reactions to be added to the backlog (which it has), it does not get closed as inactive. Also, please please read https://github.com/microsoft/vscode/wiki/Submitting-Bugs-and-Suggestions. This is not my personal advice. This is an official request from the maintainers of VS Code.

[paschalis-mpeis]

When working with different branches this would be indeed very useful.

[ds-clearago]

In #15824 this exact same problem is described, but that issue is closed because "This is now fixed.", as it says over there. I don't understand why though as this seems to be still open...

There does seem to be some movement in https://developercommunity.visualstudio.com/t/when-switching-branch-in-git-visual-studio-should/856415 though...

Do any of the extensions reliably work nowadays?

• https://marketplace.visualstudio.com/items?itemName=amodio.restore-editors (last commit 1 month ago)
• https://marketplace.visualstudio.com/items?itemName=gkotas.restore-git-branch-tabs (last commit 4 years ago)
• https://marketplace.visualstudio.com/items?itemName=iulian-radu-at.save-restore-editors (last commit 3 weeks ago)
• https://marketplace.visualstudio.com/items?itemName=avaly.restore-git-branch-tabs-improved (last commit 11 months ago)
• https://marketplace.visualstudio.com/items?itemName=santo98.tab-stasher (last commit 8 months ago)
• https://marketplace.visualstudio.com/items?itemName=mangano-ito.git-branch-wise-session (last commit 2 years ago)
• https://marketplace.visualstudio.com/items?itemName=usama8800.tab-groups&ssr=false#overview (last commit 8 months ago)
• ?

[mbonaci]

"This is now fixed.", as it says over there

I really don't know what @joaomoreno meant when he wrote that in #15824 and I couldn't ask there, because he closed the issue.
Let's see whether he responds here.

[joaomoreno]

I really don't know what @joaomoreno meant when he wrote that in #15824

Me neither. 😆

This issue is tracking this work.

[litera]

A different approach to this problem using Git worktrees

If you don't know what Git worktrees are, do check, because they're very useful. So until we actually see this VSCode feature implemented without resolving to addons, I started using Git worktrees which IMO is even better than this feature could ever be.

When I have to switch branch for some other work and not to loose whatever I've been doing in VSCode I now do this:

1. I open a new Git worktree git worktree add ../[newFolderName] [branchName] naming the folder similarly to my primary repo folder name like [repoFolderName]-temp
2. Open a new instance of VSCode
3. Open the newly created worktree folder in VSCode

This way both VSCode windows keep their separate set of open editors not interfering with my work.
Why is using Git worktrees better? Because both folders are actually the same repository, so if you change something in one branch, the other branch is aware of it automatically. When switching between worktrees, you can even keep the other git index/staged untouched so everything (including VSCode workspace) will be completely untouched. That's why I'm saying that VSCode feature can never be as good as this, because you will still have to resolve to temporary commits or stashing before switching branches.

When I'm done working on the other more urgent branch I will simply close the related VSCode window and maybe keep the worktree for later use with some other branch (hence suffixing it with temp so can be used with any branch) or simply remove it using command git worktree remove ../[worktreeFolderName].

[starball5]

@litera yep. worktrees are the workaround I suggested using in my answer to the above linked SO question.

[zwarag]

This would be a very cool feature :)

[litera]

This would be a very cool feature :)

See this: #35307 (comment)

[litera]

@litera yep. worktrees are the workaround I suggested using in my answer to the above linked SO question.

IMO this workaround is even better than out of the box VSCode feature (if implemented). Why? Because without using worktrees, one would still need to use stashing or temporary commits (to be reset upon return to this branch), because that would be Git limitation when switching branches. Of course VSCode could do it for you, but I doubt that would be part of the feature, because one may have some files as changes and others staged (may be the same file actually) and that would be way to complicated to implement so that workspace branch restore would get you to the exact same state.

So after using worktrees approach I'm certain even if this VSCode feature ever comes out, I likely won't use it, because of the reasons stated above. I'm sold on the worktrees approach. And I'd urge everyone missing this VSCode feature to start using worktrees.

[russsaidwords]

@litera I appreciate that your opinion is that worktrees are a better way of going about this than the way that another IDE might. However, coming from another IDE to Code, it is absolutely jarring that this feature is missing from the built-in workflow. Those of us coming from JetBrains products (not by choice, mind you, but by requirement of our employers) to Code are absolutely aware of the limitations of the originally proposed solution - we've dealt with it in our other IDE regularly and it's not at all a surprise when we need to commit or stash changes before switching branches. The IDE makes this painless for the developer. Proposing that people delve into their terminals for something that could be built into the interface seems like, as you said, a workaround, and, I would add, a "hacky" one at that.

I will try using git worktrees in my workflow for now, and will wait (hopefully not another ~7 years) for this feature to be implemented in Code.

Let me be clear: I appreciate that you've stated your opinion. I appreciate all of the hard work that goes into making an editor such as Code. I appreciate that there are workarounds available. I am only actually upset that I can't use my IDE of choice at my place of employment and wish for all software, Code included, to improve over time. Given a proper settings flag to enable or disable this feature so that all parties could use it or not at their whim would, I believe, be a great win for all developers using Code.

[litera]

@russsaidwords: I will try using git worktrees in my workflow for now, and will wait (hopefully not another ~7 years) for this feature to be implemented in Code.

You do realise there are a few addons for VSCode that have certain capabilities within VSCode you're looking for? So that you don't have to use terminal.

But even regarding the terminal. You're correct. You do need to use the terminal or shell or whatever you please. But that's only actually needed when you create a worktree. If you decide to use it longtime, you can then do it all in VSCode. Open the directory of the worktree in VSCode, checkout branches, pull, push, commit... No need for the terminal any more after a worktree is created and running.

[russsaidwords]

@russsaidwords: I will try using git worktrees in my workflow for now, and will wait (hopefully not another ~7 years) for this feature to be implemented in Code.

You do realise there are a few addons for VSCode that have certain capabilities within VSCode you're looking for? So that you don't have to use terminal.

Indeed, I do realize that as I've read the discussion up to now. Why not have an official extension for performing such operations? Why not have an official extension that changes files based on the branch? This is precisely what JetBrains have done, and it works fabulously - I suggest you try their IDE for your language if you never have before.

But even regarding the terminal. You're correct. You do need to use the terminal or shell or whatever you please. But that's only actually needed when you create a worktree. If you decide to use it longtime, you can then do it all in VSCode. Open the directory of the worktree in VSCode, checkout branches, pull, push, commit... No need for the terminal any more after a worktree is created and running.

I'm not going to go into details here or talk about workflows with worktrees, except to say that in my limited experience with them and my major experience with a branch based file changing workflow (as the feature requested in this ticket), the second way is superior. This is my opinion. You have expressed yours. Your opinion that the workflow with worktrees is superior is that - your opinion. Others want the option to have a different way. That is all I will say more on this subject.

Thank you for your input.

[lszomoru]

Today's VS Code Insiders release (version details below) contains the first iteration of the ability to associate editor working sets (editors, layout) with a source control branch. You can enable this feature using scm.workingSets.enabled setting. You can also use the scm.workingSets.default (current, empty) setting to control the behaviour of switching to a branch that does not yet have a saved editor working set.

Please enable the feature, try it out, and let us know your feedback. Thank you!

Version: 1.89.0-insider (Universal)
Commit: 50a6f4f200c5a33f47997eb6a8966e50cf219e21
Date: 2024-04-12T05:52:00.589Z
Electron: 28.2.8
ElectronBuildId: 27744544
Chromium: 120.0.6099.291
Node.js: 18.18.2
V8: 12.0.267.19-electron.0
OS: Darwin arm64 23.4.0