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!

[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

[diminutivesloop]

@lszomoru Just tried it out and it works great! I do wonder if the language in the settings is a little obscure. I don't think it would be clear to someone who hasn't been following this issue what exactly "working sets" are.

[lszomoru]

@diminutivesloop, thanks for the feedback. The current plan is to include this feature in the next Stable release, but do not yet enable it by default. We will use the next milestone to gather feedback and adjust the feature based on that. As part of that work we will also see if there is better terminology that we can use.

[jtaylor-zuora]

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

works pretty well so far for me. I notice that if I switch branches from the terminal, it loses focus after the editor state is restored. It would be nice if the focus stayed in the terminal. Otherwise, I like it!

[lszomoru]

@jtaylor-zuora, thanks for the feedback. I have filed #211621 to track this issue.

[lszomoru]

This feature will be available in VS Code stable (1.89) towards the second half of this week.
I will go ahead and close this issue and any additional feedback related to this feature will be tracked separately.

[brandonmcconnell]

I gotta say, I never thought I'd see this issue resolved. I'm almost gonna miss all the notifications about new comments in this thread. 🥹

Good work, everyone involved. Solid fix.

[zwarag]

Thank you all for the great work. This is a great feature ❤️

[starball5]

Nice. I've updated my various SO answer posts (this and this)