LMMS
Git ignore the .vscode folder
Add a Git ignore for the .vscode folder. This is for people who use Visual Studio Code as their development environment.
For me, the default install target is the ./out folder. I wouldn't mind adding that folder as well.
For me, the default install target is the
./outfolder. I wouldn't mind adding that folder as well.
Would using a personal ignore file be an option for you? Quote:
You can also define personal ignore patterns for a particular repository in a special file at .git/info/exclude. These are not versioned, and not distributed with your repository, so it's an appropriate place to include patterns that will likely only benefit you.
I'd argue that build/install directories are rather a personal preference whereas the .vscode ignore benefits all people who use Visual Studio Code as their IDE. So in my opinion it makes sense to have the latter in the repository wide Git ignore.
I'd argue that build/install directories are rather a personal preference
Counter argument: build and target are already part of the ignore list.
whereas the
.vscodeignore benefits all people who use Visual Studio Code as their IDE
I am using Visual Studio as my IDE, too.
While you're at it, maybe you could change the /build line at the top to /build*?
That way I can have multiple build directories of my choice, for example build_release and build_debug.
I'd argue that build/install directories are rather a personal preference
Counter argument:
buildandtargetare already part of the ignore list.
Yes, but these are also part of the "Compiling LMMS" how-to. So they are the "officially sanctioned" way to build and install LMMS during development.
Adding tons of options for individual developers would clutter the .gitignore file in my opinion. In the worst case at one point there would be lots of ignores for developers that have stopped developing the software and no one knows if it is "safe" to delete these entries.
whereas the
.vscodeignore benefits all people who use Visual Studio Code as their IDEI am using Visual Studio as my IDE, too.
Do you use Visual Studio Code or something like Visual Studio Community edition? Visual Studio Code stores most of the user specific settings in files under .vscode. I am not sure if this is also the case or Visual Studio Community Edition and Co.
I'd argue that build/install directories are rather a personal preference whereas the .vscode ignore benefits all people who use Visual Studio Code as their IDE. So in my opinion it makes sense to have the latter in the repository wide Git ignore.
Someone who uses this IDE feel free correct me, but I believe Visual Studio uses .out and/or bin for their build directories by default. I do not see why these directories can't be added. These wouldn't be a personal preference if they are the defaults for the IDE.
Someone who uses this IDE feel free correct me, but I believe Visual Studio uses
.outand/orbinfor their build directories by default. I do not see why these directories can't be added. These wouldn't be a personal preference if they are the defaults for the IDE.
@Veratil, @sakertooth, if the .out and bin directories are the default that's generated for Visual Studio builds then we should definitively add them as well. Sorry, I thought it was just some personal preference when setting up the build.
Can someone give me the exact directories that have to be added for the Visual Studio default build? I do not have Visual Studio.
We discussed the desired approach to .gitignore a while back, and concluded that each user should put their own IDE files and folders in .git/info/exclude locally. I'll try to find the conversation. As for Visual Studio, CMake should generate project files with the appropriate output directories, so the defaults shouldn't be relevant.
We discussed the desired approach to
.gitignorea while back, and concluded that each user should put their own IDE files and folders in.git/info/excludelocally. I'll try to find the conversation. As for Visual Studio, CMake should generate project files with the appropriate output directories, so the defaults shouldn't be relevant.
Well, there goes this PR, lol.
Edit: This is the conversation.
rossmaxx — 09/10/2023 8:04 AM I do plan to use VS Code with lmms i remember creating a workspace once and gitignoring the files i fiddled with this a bit before
Dom — 09/10/2023 8:07 AM We don't put IDE directories in our .gitignore file, since they're specific to indvidual users' workflows. Instead, you'll need to open .git/info/exclude in the LMMS source directory, and add the line .vscode/ in there somewhere. This may not be trivial to open - .git is a hidden folder, so it won't show in File Explorer by default, and VS Code hides it by default as well.
Should we close then?
We don't put IDE directories in our .gitignore file, since they're specific to indvidual users' workflows.
But it really doesn't hurt to put some defaults in there does it? What issue will be caused by adding things like .vs and .vscode to the ignore list?
I also don't understand what are the arguments against providing sane defaults for widely used IDEs.
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. I have never needed the file because I seem to have only worked in projects which had nice default ignore files.
Why make every developer jump through hoops to get a nice development experience? Especially in the light of the "Make developing more attractive" issue that has bubbled up today? I think it leads to a worse developer experience.
But it really doesn't hurt to put some defaults in there does it? What issue will be caused by adding things like .vs and .vscode to the ignore list?
I agree, but I understand both sides of the coin. For certain directories, it would seem nice if you don't have to remember to add it in .git/info/exclude, especially if they're associated with fairly common IDE's. However, when using things like clangd that has their own .cache/clangd directory, that would very specific and should probably be in .git/info/exclude and not .gitignore.
So the problem seems to be how specific of the workflow are we talking about. I do not mind adding common directories like .vscode, out, and bin to the main .gitignore. It can add a bit of convenience for a lot of developers without much clutter. Such IDEs will most likely not "go under" anytime soon and stop being used on a global scale, so such directories will most likely be relevant for a while.
I agree, but I understand both sides of the coin. For certain directories, it would seem nice if you don't have to remember to add it in
.git/info/exclude, especially if they're associated with fairly common IDE's. However, when using things like clangd that has their own.cache/clangddirectory, that would very specific and should probably be in.git/info/excludeand not.gitignore.
I'd argue that even something like .cache/clangd might go into the .gitignore if it is a technical component that's potentially used by several developers in some default configuration. There's almost zero chance that the entry would mask a file that should be added in the context of LMMS itself but now does not show up in the diff. Put differently: it would not hurt in any way and might serve several developers.
So the problem seems to be how specific of the workflow are we talking about. I do not mind adding common directories like
.vscode,out, andbinto the main.gitignore. It can add a bit of convenience for a lot of developers without much clutter. Such IDEs will most likely not "go under" anytime soon and stop being used on a global scale, so such directories will most likely be relevant for a while.
Fully agree.
This may not be trivial to open - .git is a hidden folder, so it won't show in File Explorer by default, and VS Code hides it by default as well.
That's another convincing argument for adding these entries to the .gitignore.
https://github.com/github/gitignore This repo contains gitignore templates for various editors, tools and OSes. Not saying pull in entire files, but would be nice to get an idea of just how many extra things can be generated that we don't actually want.
https://github.com/github/gitignore This repo contains gitignore templates for various editors, tools and OSes. Not saying pull in entire files, but would be nice to get an idea of just how many extra things can be generated that we don't actually want.
Thanks for the link! Some interesting files in there...
The discussion I was thinking of was #5062. The vote was 7-1 in favour of users ignoring their IDE files locally. Restricting to users who appear on the contributor list, it's 6-0. (@JohannesLorenz do you want to weigh in on this discussion, since you authored the last one?)
maybe you could change the
/buildline at the top to/build*
This is the sort of personal workflow thing I'd rather leave out of .gitignore even more than IDE files and folders. I very much agree with the author's sentiment:
Adding tons of options for individual developers would clutter the
.gitignorefile in my opinion. In the worst case at one point there would be lots of ignores for developers that have stopped developing the software and no one knows if it is "safe" to delete these entries.
I'd also like to be cautious about including more wildcard patterns than absolutely necessary.
As for setting up .git/info/exclude, it's not difficult, only needs doing once per clone, and needs to be done anyway for anyone with their own workflow preferences. For those who aren't aware of it, we can mention it in the wiki along with other setup steps. In fact, we should probably do so regardless of the outcome here, for the benefit of those with more obscure IDE choices.
In the worst case at one point there would be lots of ignores for developers that have stopped developing the software and no one knows if it is "safe" to delete these entries.
Yes but... we can add comments to any line or section we want. 😁
# this is a comment in .gitignore
some/path
Yes but... we can add comments to any line or section we want.
The original author of an ignore pattern being gone doesn't guarantee that no-one else is using the configuration. Leaving it to individual users does. Also, given the number of people still in the LMMS GitHub organisation who haven't been seen for years, we're not good at cleaning this sort of stuff out.
The discussion I was thinking of was #5062. The vote was 7-1 in favour of users ignoring their IDE files locally. Restricting to users who appear on the contributor list, it's 6-0. (@JohannesLorenz do you want to weigh in on this discussion, since you authored the last one?)
Looking at that linked discussion, it states that .vscode/ should not go into our local .gitignore.
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). However, looking at that cite
Patterns which are specific to a particular repository but which do not need to be shared with other related repositories (e.g., auxiliary files that live inside the repository but are specific to one user’s workflow) should go into the $GIT_DIR/info/exclude file.
IMO .vscode is not specific to a particular repository, because you can use VS Code for multiple projects. The global gitignore (on Linux ~/.config/git/ignore, on Windows %USERPROFILE%\.config\git\ignore) seems the right place.
If another project really does want to add .vscode, you can still overwrite your global gitignore with the local gitignore (adding !/.vscode/). This makes sense because most users will globally ignore their .vscode.
Summarizing, I think .vscode should be removed from this PR. The rest is valid improvement though.
For me the most relevant difference is that having to add the ignore globally translates to "Every contributor has to do these steps and might not know that they must be performed" whereas defining it in the local git ignore translates to "No contributor has to do these steps and gets functionality for free". The latter is a "batteries included" approach which is under the full control of the project itself.
I think this is even more valuable in the light of attracting new contributors who might not be so experienced and who might be intimated by long lists of what needs to be done to get going in the first place.
I think this is even more valuable in the light of attracting new contributors who might not be so experienced and who might be intimated by long lists of what needs to be done to get going in the first place.
Agreeing that it might help new developers. On the other side, if new developers will be surprised that their .vscode folder is visible in git status, they will ask us, and we will tell them about the global gitignore, which, otherwise, they would not have found.
Well. The rules say let's not include it. We will also not die if we break the rules. Should we start a voting? :grinning:
I think this is even more valuable in the light of attracting new contributors who might not be so experienced and who might be intimated by long lists of what needs to be done to get going in the first place.
Agreeing that it might help new developers. On the other side, if new developers will be surprised that their
.vscodefolder is visible ingit status, they will ask us, and we will tell them about the globalgitignore, which, otherwise, they would not have found.
While I really like this sense of community I'd personally still favor "Don't let people run into a problem" over "Let people run into a problem but we will help them". I can imagine that also having to learn about the intricacies of git might be unattractive to new contributors who also have to get acquainted with the code base, doing builds, etc.
Well. The rules say let's not include it. We will also not die if we break the rules. Should we start a voting? 😀
I don't want to be the guy who stirs up things especially if it has already been discussed and voted on. 😅 On the other hand there have been several contributors in this comment section already who were in favor of the changes. So the result might not be as clear as the previous "7-1" ("6-0") depending on the audience that you ask.
If the audience contains many inexperienced developers the result might be in favor of the local ignore and if you ask many experienced developers who know git they might be against it.
I don't know if my vote was in there or not, but my vote is to include the ignore in our file.
Seems like this will be the final consensus. :sweat_smile:
It's now only ensured that build and target are directories.