I don't agree with this change, and I'll refer you to this StackOverflow comment from a member of the VSCode team which provides context:

Check in the .vscode folder if you want to share settings, task configuration and debug configuration with the team. I think generally it makes sense to share settings (e.g. whitespace vs tabs) with the team if you want to enforce settings in a team. We in the VS Code team share debug and task specific settings as well because we want our team to have the same set of debug targets and task targets for VS Code.

You are welcome to ignore the VSCode directory for specific projects, but I believe the current set of rules make sense as a good default for VSCode users

I'll quote part of the aforementioned comment (my emphasis):

I think generally it makes sense to share settings (e.g. whitespace vs tabs) with the team if you want to enforce settings in a team.

So this only make sense if you want to enforce settings in a team. Which is not something a general .gitignore should enforce. Instead, this should be a conscious decision made by the team.

There's two extra points I want to make while we're in here discussing this:

• these templates are intended to be a reference for what can be stored in Git, and teams and projects are welcome to adapt and combine things to suit their needs
• in situations where things may be useful to have in version control (where there as pros and cons to a rule), we favour being conservative and providing more information about what can be tracked in Git

Another option we've done in the past is to include comments alongside rules to add context about the situations in which you may want to enable or disable a rule.

For example:

We could include a comment like this before the current rules:

# by default all files in this directory should be ignored in Git
.vscode/*

# these rules can be shared with collaborators
# delete these lines if you do not wish to share these config files
!.vscode/settings.json
!.vscode/tasks.json
!.vscode/launch.json
!.vscode/extensions.json

@openMedi does that feel like a decent compromise here? Personally, that list of "these files can be committed" feels important to have around, even if its usage is a bit nuanced in the wild.

Thanks for enganging with this issue. I think it's a nice idea to inform people about what is possible, however I do think that people should comment in (as opposed to out) non-essentials.

So, I think this would be better:

# by default all files in this directory should be ignored in Git
.vscode/*

# these rules can be shared with collaborators
# uncomment these lines if you wish to share these config files
# !.vscode/settings.json
# !.vscode/tasks.json
# !.vscode/launch.json
# !.vscode/extensions.json

Any update?