-
Notifications
You must be signed in to change notification settings - Fork 30.1k
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
Enable opting out of workspace settings / .vscode/settings.json
#206802
Comments
Primary intention of workspace/repo settings is to allow users collaborating with that workspace to have similar and stream lined experience. Ignoring it can lead to issues like breakages. I do not think it is a good idea to allow such a feature in the product that can break the team experience. If a user does not like or change some settings/guidelines, it is recommended to make that change in the team guidelines. |
The current situation breaks the team experience as it forces me to have to convince my colleagues to change settings or for me to do workarounds, like patching the checked out repo or swapping to another editor (or disabling the extensions that eg are configured to do auto formatting) A team experience is enforced through CI and scripts, not through UI. Also: When forking a GitHub repository to do PR:s I will get the team settings of a fully unknown team and will get random surprises in how the editor works depending on which repository ai’m currently contributing to, with no way of really knowing what changes and when. It disrupts my muscle memory and can’t be fixed by “talking to my team”. I should be able to make PR:s with VSCode without being forced upon the settings of other teams. (I maybe can achieve this by marking the repo as not trusted, but that’s very disruptive and far further reaching. It’s not that I don’t trust them, it’s that I can’t instantly adapt my muscle memory to each and every project I contribute to) At least leave it open for some discussion? And then close it as “not planned” rather than “completed” when closing? 🥺 |
Thats right and team settings should help in catching any CI failures upfront and make it efficient.
I can do this to make you happy, but I have to say this is out of scope feature. |
Only holds true when one is also enforcing the editor of choice and especially when contributing to open source projects editors will not be forced upon contributors, so not sure why settings should be. For future reference to others finding this issue: One can use the git update-index --assume-unchanged .vscode/settings.json |
Unlike #40233 – which is about separating local workspace settings from shared workspace settings – I would primarily want a way to disable workspace settings in its entirety.
Most basic solution of all:
Have a user setting that disables the use of workspace settings.
Why do I want this?
I sometimes get very confused when I open up a repository shared with someone else and all of the sudden my editor starts eg. formatting on save etc when I work with files there – and even when I figure that out there's no way for me to avoid it other than convincing my collaborators to remove the workspace settings from the repository.
I can never think of a scenario where I personally would prefer to use settings from someone else, but I can see how others may like it.
Having an option to opt out of the shared settings would help avoid a lot of conflict and friction within teams and projects.
Is this a duplicate?
Unlike eg. #40233 and #89737 (which was marked a duplicate of #40233) this isn't about individual rules, this is about opting out of workspace settings entirely.
The text was updated successfully, but these errors were encountered: