Provide ability to define workspace specific settings from outside the workspace

[weeblr]

Hi

When I open a git-controlled folder, and possibly change some settings, then Code creates a .vscode directory directly inside that folder, and stores files such as settings.json or launch.json in it.

That folder either has to be checked in or .ignored, which is OK on repos I control, but not OK on forked repos I want to contribute to for instance, which needs to stay clean.

Can't this data be stored in some Code own data folder?

Cheers

[bpasero]

These things are workspace related settings so they are stored in the workspace folder with the intent to share them to other people (e.g. a launch configuration is typically OS and path independent).

You don't have to create workspace settings, there is also user level settings. For launching and tasks however, these files are stored within the workspace.

[weeblr]

I get your point. Indeed making that workspace specific settings live inside the folder makes it shareable.
But it does mean I cannot use workspace-specific settings and launch configuration on repos I don't control.

Intelij IDEA stores that meta data either in the workspace folder or in a separate, IDE-owned, folder so that repos are kept clean.

Cheers

[alexdima]

@weeblr Here is a nice trick I use for this 😉

Edit .git/info/exclude and add .vscode

Hint: works like a .gitgnore file sitting in the root of the repo, but that is not checked in the repo

[weeblr]

Hi alexandru,

thanks for the tip. Nice workaround. That doesn't really change anything to the problem however. That folder will still be included in tar balls and such.

vscode should just leave the edited code alone.

Cheers

[alexdima]

@weeblr fair point

[felixfbecker]

This should be closed as working as intended

[fr43nk]

This would be a nice feature. My project is connected to network drive. This contains folder which are writeable but the root is read only so the vscode has no chance to store the settings file.

[bpasero]

We are planning to support this eventually, stay tuned 👍

[fleps]

Any news on this? Have the same issue, need to configure some nice-to-have VSCode tasks but can't do that because it creates a .vscode folder inside my shared workspace/repo where I can't edit the gitignore =(

[MathiasMagnus]

Just as a comment, in case someone would not open the mentioned issue (#41139) consider the use case depicted there. My launch.json may look radically different on Windows and inside WSL.

In my actual case it's just the type of the C++ debugger and the paths to files in command-line arguments, where in one case it's C:\Users\... and in the WSL case /mnt/c/Users/.... If others have targets for publishing code, that will look totally different though, packaging and publishing for a Chocolatey repo and an Ubuntu PPA certainly look and feel different.

Duplicating the source tree only to make room for two launch.json and two settings.json is tedious. Plus it bring the added aggravation of fixing one issue on Windows/MSVC and if I want to check whether it wrecked builds or introduced warnings on Ubuntu(WSL)/GCC I have to migrate commits by pushing to a repo visible by both. It's just not productive.

[sandy081]

This can be solved by using new Workspace (Multi-root) concept. You can open the folder in a workspace as follows:

• New Workspace
• Add Folder

And, settings and debug configurations will be local and no .vscode folder is created in the added folder. If you want to reuse the configuration, you can save the workspace (locally).

Closing this in favor of using Workspace.