-
Notifications
You must be signed in to change notification settings - Fork 28.6k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Git Checkout: Add save and recall editor files on branch change #26568
Comments
@cleidigh While it isn't ideal and has a bunch of caveats you could use Restore Editors to save your set before the checkout and restore them after. |
This isn't directly related to Git. Our recommendation is to use an extension such as Restore Editors. |
@joaomoreno @eamodio |
@cleidigh its been requested and PRs are welcome ;) I've just been hesitant to add too much to it because of the hackery and caveats required by the current implementation. Once vscode adds support for #15178 then I will be happy to put more features into it :) Eventually I could see it come close in functionality (albeit with different UI) as my VS "proper" extension Save All the Tabs |
@eamodio |
@eamodio |
@cleidigh honestly I couldn't say -- it doesn't look like there has been much movement on this. The big issue is the hacks I use in GitLens and Restore Editors are extremely fragile -- I keep finding cases where it ends up looping forever. :( And I think even to just get things to a place where Restore Editors could get the basics work -- there would need to be an API (or command) to get the list of all the "opened" tabs (Uri, viewColumn, and order ideally). And then I'd need an API/command to close an editor given a Uri. With those I think I could get the rest to work. An alternative would be a command (or something) that would cause Yet another alternative would be for vscode to implement 2 new commands -- That way an extension could do something like I dunno -- I'm just rambling now ;) |
@eamodio BTW I like the save and restore layout, agree that this is probably the most doable. |
Yeah, not sure how the multi-root stuff would affect this, although I'm not sure it would have much of an impact, if we are just saving location and layout of Uris -- could work even if no folder was open. @jrieken any thoughts on the above -- most specifically the last option (but it could be a couple of methods on workspace rather than new commands) If something like that would be an acceptable addition -- I'd be happy to collaborate on a PR with you @cleidigh |
@eamodio I took a quick look at workbench and basically only need is to replicate the open and close of the active editors and expose them in some expedient way (as you pointed out). Should not be that big of a deal. If the save and restore commands are part of the general user command palette , I would think that From an extension perspective , you have almost everything you need structurally and with quite a bit of parallelism with your stash feature. |
When moving between branches the working git file space obviously changes to the requested branch .
The open editors remain the same, yet typically one would be working with a different set of files
for the different branch.
Proposal:
git workspace command/option git.saveEditorFileSetOnCheckOut
(or something of the sort)
probably give the user option to recall or not on branch change.
I would sign up to work up on this if deemed useful.
The text was updated successfully, but these errors were encountered: