Git Checkout: Add save and recall editor files on branch change

[cleidigh]

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.

[eamodio]

@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.

[joaomoreno]

This isn't directly related to Git. Our recommendation is to use an extension such as Restore Editors.

[cleidigh]

@joaomoreno
Tudu bem ;-)
Understand makes sense to keep separate...

@eamodio
Maybe adding multiple named file sets to your extension would do just the trick !

[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

[cleidigh]

@eamodio
totally makes sense, one can only hack so much ! then it all has to be undone ;-)

[cleidigh]

@eamodio
Just curious do you see the API going anywhere? I keep wanting this feature as I switch between
feature or bug branches. I envision something like git stash or file sets. I am wondering
if this is something I could look into working on. BTW CodeLens rocks!

[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 workspace.textDocuments to not be lazy and actually return all the "opened" documents (not a 1-1 with a tab, but would get most of what you'd want). Then would want an API/command to go from a TextDocument to an editor, and an API/command to close an editor given a Uri.

Yet another alternative would be for vscode to implement 2 new commands -- saveLayout & restoreLayout (where restore could take an option to close all first or not). And both commands would take a name or key. Honestly this option while less ideal than a real tab model, is probably the path of least resistance.

That way an extension could do something like commands.executeCommand('vscode.saveLayout', { name: 'slot-1' } which gets serialized and stuffed into some local workspace storage or something, and then later could call commands.executeCommand('vscode.restoreLayout', { name: 'slot-1', closeAllFirst: true } to recall that stored set.

I dunno -- I'm just rambling now ;)

[cleidigh]

@eamodio
Sorry for this snail response...
other than the hello world I really only worked inside VSCode. I'm really unfamiliar with the API
limitations or otherwise. I'm going to do a small PR for Compare active file with... that shows
the active file in the drop-down which is a bug since you can't compare to self. This should give me
a glimpse on the inside of the structures for the editors. Perhaps I can look into this later. I'm not sure how open the team is to expanding the extension API. I also wonder how much the multi- folder
additions will affect the effort.

BTW I like the save and restore layout, agree that this is probably the most doable.

[eamodio]

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

[cleidigh]

@eamodio
Absolutely. I really think this is a fairly basic feature. I started the thread based on the idea that when doing any repository work with multiple branches, one is always bouncing between file sets. For me,
being a disabled/Dragon voice control user, drag-and-drop, mouse operations or dealing with file trees
is terribly painful.

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
they would have to be complete including a picklist et cetera. Ideally we could do something less internally and more in an extension but I'm not sure how those types of commands would fly.

From an extension perspective , you have almost everything you need structurally and with quite a bit of parallelism with your stash feature.