ignore .vscode/ folder

[anytizer]

Helps to use VS Code as code editor.

[michaelgregorius]

Good luck with that! I tried the same and you can find a long discussion here: #6884.

[allejok96]

The discussion says that such files should go into a .git/info/exclude or into %USERPROFILE%.config\git\ignore (Windows) or ~/.config/git/ignore (Linux).

I am a professional software developer and have only learned today about .git/info/exclude while searching for a solution for potential individual ignore setting.

we can add comments to any line or section we want
# this is a comment in .gitignore

Then the solution to this issue would be to put a comment there to tell the dev to edit .git/info/exclude instead

[michaelgregorius]

On the other hand this new PR might be a good indicator that Visual Studio Code is used by several developers and that it might really help to add that single line to the .gitignore. 😉

[anytizer]

.vs, bin, obj, Debug, Release are used by Visual Studio IDE. These folders happen to fall under build/ folder, and no need to do anything, as I remember trying to compile LMMS within Windows.

The other popular IDEs are Visual Studio Code and CLion.
Visual Studio Code uses .vscode folder at the root of the project. Hence, I suggest, we include vscode in .gitignore file.
CLion users may suggest adding .idea in the .gitignore.

It would not hurt making the application compatible to many IDEs, and let .gitignore serve its purpose.

/.vscode
/.idea

Since, these directories are not due to individual preferences, it should be better considered to .gitignore them.
Ideally, I would not touch anything inside .git folder, manually.

BTW, which IDE do you use?

[allejok96]

I use Qt Creator, it doesn't store stuff in the project directory I think.

IMO the argument that adding this to gitignore would "clutter" it seems silly. I mean if you think that is clutter then you shouldn't look at LMMS' codebase, bless your heart. And in what future scenario would having an obsolete /.vscode in gitignore be a problem? If it makes people's life a little easier, just add it, it doesn't cost anything.

[rdrpenguin04]

If I recall correctly, the default gitignore templates GitHub provides for the languages I've seen have a section dedicated to IDE-specific files and folders. This is not unprecedented. I'd concur with adding IDE folders to the gitignore.

[JohannesLorenz]

There was the voting, like michaelgregorius mentioned. Feel free to restart a voting, but IMO, doing this without a voting would be weird.

I can just picture my arguments:

# IDE folders (exaggerated, but by far incomplete looking at the number of IDEs and editors that exist, or their extensions)
.idea
.vscode
.codeblocks
.atom
.devcpp
.codelite
.clion
.vi
.vim
.qtcreator  # yes, I know, not all of these exist
.emacs
.netbeans
.whateverIDEfolder
.whatevereditorwhichisnotevenanIDE

# build directories
build2
build3
gcc
clang

# other stuff some users might use
a.out
.gdb_history
CMakeLists.txt.user
.notes
Trash
lost+found
.thumbnails
__pycache__ # some users surely use python to parse some LMMS logs?
moreThingsLikePyCacheForOtherLanguages

If every developer adds things that a few developers might need, i.e. puts half of their global gitignore into our local gitignore, we end up with big, redundant blocks. I would not want to add such blocks into all projects in all repos. And IMO a master history should not look like this:

* bugfix
* adding IDE1
* bugfix
* adding IDE2
* adding IDE3
* new feature
* fixup of adding IDE3
* adding IDE4
* crucial bugfix
* adding IDE5
* adding a folder to gitignore that is not even an IDE

This makes finding crucial commits just more difficult (or overseeing them more easy).

[rdrpenguin04]

The counterpoint to this is that a lot of developers don't have global gitignores, so each one has to manually exclude .vscode from their commits.

If, occasionally, someone forgets and commits it anyway, and it makes it into the PR, that wastes someone else's time to say "please remove your .vscode directory from your commits" and you get a back and forth discussion on how to do that without losing local changes because this is a fairly unintuitive part of using git, then explain how to put it in their global .gitignore... and that happens how many times? Once for every PR that makes the mistake.

On the other hand we can add the folder now and avoid that drama later.

To avoid this becoming a slippery slope (I doubt it would anyway, and I doubt it would be a big deal if it did, but I digress), there's a fairly easy check: have three or more people voiced that they want a folder ignored? In this case, a more than sufficient number of people have cause for .vscode to get ignored, so it should. For other files and directories, maybe it's a different story.

... but also, adding a ton of folders to the gitignore at once from the beginning would solve that problem too. Having a big gitignore is not actually an issue; it's better to cover the bases at a project level rather than deferring the task of fixing it to reviewers. We could honestly just collect a list of IDE folders and merge them all at once.

[rubiefawn]

While I'm not a vscode user, I recognize it is an extremely common code editor. Having read both the discussion in this PR as well as #6884, I think the reduced friction this provides to current and future contributors using vscode is worth it.

[bratpeki]

Yeah, ignoring IDE configs sounds pretty damn smart.

If we find a tasks.json or launch.json that benefits all users, then definitely add it with git push -f. But until then, no reason to not reduce friction from people who git add . or something :)

[bratpeki]

This does leave the target and build directories mentioned in 6884. I use build, it's what I referenced in the MSYS build instructions, too.

We're leaving those untouched, I hope?

[Rossmaxx]

I am in favour of adding /.vscode (and other common IDE folders) in gitignore. I read the other PR discussion in the past but forgot most of it. I don't think adding 2-5 lines would clutter the gitignore file, rather I feel it makes things easier. About the rest of the more niche stuff, they can go in the per user ignore file, but for something which 90% of the devs use, forcing them to use the per user ignore file just to keep the gitignore clean is not really good developer experience (correct me if i'm wrong)