"Workspace settings" are lost when switching between worktrees

[ELLIOTTCABLE]

Issue Type: Bug

I just upgraded to GitLens Pro, specifically for worktree-support.

However, I use a lot of workspace-scoped settings. When you use GitLens's features to "switch" to another worktree, you're effectively changing workspaces, as far as VScode is concerned. This means all of the workspace-specific settings are reset to their default values.

My current workaround is pretty nasty: I save the workspace as a file, and every time I create a new worktree, I duplicate the .code-workspace file for the original worktree, and update the paths stored in it. It's a pretty gross and manual process, though; so it'd be super-awesome if GitLens would automate it.

Extension version: 12.0.5
VS Code version: Code 1.66.0 (e18005f0f1b33c29e81d732535d8c0e47cafb0b5, 2022-03-30T05:49:37.118Z)
OS version: Darwin arm64 21.4.0
Restricted Mode: No
Remote OS version: Linux x64 5.8.0-0.bpo.2-amd64
Remote OS version: Linux x64 5.8.0-0.bpo.2-amd64

System Info

Item	Value
CPUs	Apple M1 Pro (10 x 24)
GPU Status	2d_canvas: enabled canvas_oop_rasterization: disabled_off direct_rendering_display_compositor: disabled_off_ok gpu_compositing: enabled metal: disabled_off multiple_raster_threads: enabled_on oop_rasterization: enabled opengl: enabled_on rasterization: enabled raw_draw: disabled_off_ok skia_renderer: enabled_on video_decode: enabled video_encode: enabled webgl: enabled webgl2: enabled
Load (avg)	4, 5, 5
Memory (System)	16.00GB (0.06GB free)
Process Argv	--crash-reporter-id ddb5da65-4654-412e-9dc3-738998ade011
Screen Reader	no
VM	0%

Item	Value
Remote	SSH: febox3
OS	Linux x64 5.8.0-0.bpo.2-amd64
CPUs	AMD EPYC 7413 24-Core Processor (48 x 2298)
Memory (System)	502.99GB (11.55GB free)
VM	0%

Item	Value
Remote	SSH: febox3
OS	Linux x64 5.8.0-0.bpo.2-amd64
CPUs	AMD EPYC 7413 24-Core Processor (48 x 2298)
Memory (System)	502.99GB (11.55GB free)
VM	0%

[DerJFK]

This seems to me an important feature. Creating a working tree should copy the .vscode directory to the new directory. Maybe with a filter to decide which files from .vscode are copied.

[cojua8]

It also seems like a nice feature to have.
Workspace settings contains many useful configuration for my projects, that i'd like to share (and keep sync) between branches.

[eamodio]

Copying over the .vscode folder imo is outside the scope of this -- as usually the .vscode folder is checked in, so it would automatically be there already.

As for workspace specific settings, I can certainly see the desire, but sure exactly how go about resolving it.

If you open a workspace (a *.code-workspace), and you create a new worktree, we could create a new *.code-workspace for that worktree (though not sure exactly where to save it -- maybe it defaults to inside the GitLens storage folder and a user can choose another folder?) and then automatically copy over all the settings from the current workspace into the new one.

Would something like that work for you all?

[cojua8]

@eamodio, for team projects, the .vscode directory is not always checked in, as every developer uses the editor they like

[wardyment]

Just discovered this feature and love it. In my case the *.code-workspace is checked in etc. However when I switch between worktrees the default setup is to just show the root of the directory (not the workspace).

Would be good to perhaps have an option to automatically open a workspace if it exists when switching worktrees.

[wardyment]

Another idea is you could provide a hook afterWorktreeCreated and then users could run whatever command they wanted. e.g copy files, open workspaces

[ELLIOTTCABLE]

This is surprisingly complex. Maybe we need a table of the ("project"-related setting location + checked-in status of that location) against the (whether that setting should be persisted when creating a worktree for a branch, and approach to persisting it …) 💀

Making this work at all might be a bit heavy on configuration — i.e., for example, since there's so many different places a configuration-setting could be, the only reliable option might be to just create a new superior-priority configuration (.vscode dir?) for the new worktree, and manually copy a whitelisted set of configuration-options over into the new config, regardless of where they were set in the previous configuration-cascade …