First and foremost I think that requiring such a complicated gitignore for JetBrains IDEs is a failure on JetBrains part in structuring their project setting. I also feel that it should be included in the `Python.gitignore` due to its popularity and due to the frequency of requests. A quick search for `PyCharm` PRs shows 81 closed PRs requesting it be added and if searching for `.idea` you can see many more have been requested. However I understand the maintenance burden in including it when a user can manually merge the two files themselves so I understand why the maintainers have opted to maintain it seperately.
The main problem I see is that with many people adding the `Python.gitignore` at project creation through the Github UI and the `JetBrains.gitignore` being in the Global folder and makes it less discoverable than it should be.
This PR adds a comment for people adding the `Python.gitignore` directing them to the global `JetBrains.gitignore` which should solve this issue in a way that is acceptable for the maintainers, since comment-only sections already exist for `pyenv` and `pipenv`.
_ModuleInstall/TcFilter/TwinCAT CE7 (ARMV7)/TcFilterW32.dll
_ModuleInstall/TcFilter/TwinCAT CE7 (x86)/TcFilterW32.dll
_ModuleInstall/TcFilter/TwinCAT RT (x64)/TcFilter.sys
_ModuleInstall/TcFilter/TwinCAT RT (x86)/TcFilter.sys
After contacting Beckhoff support, it was concluded that the folder "_ModuleInstall" could be omitted from version control, thus this addition.
After running `yarn set version berry` and `yarn install`, the file `.yarn/install-state.gz` is created.
The documentation at https://yarnpkg.com/advanced/qa#which-files-should-be-gitignored mentions that this file should be ignored:
> .yarn/install-state.tgz is an optimization file that you shouldn't have to ever commit. It simply stores the exact state of your project so that the next commands can boot without having to resolve your workspaces again.
The documentation has a minor error; the generated file is `.gz` instead of `.tgz` (source: https://github.com/yarnpkg/berry/pull/998/files#diff-23dd4c2e823c25186f1107e88e962032R201)
pip generated this folder for a few versions, as part of it's initial
implementation of PEP 517.
pip has not generated this folder for a few versions now, so it should
be OK to remove this from the standard gitignore file.
Visual Studio .Net used Win32/ as one of the default output directories for C and C++ projects. Later, when 64-bit support was added to the toolchain (circa 2005), x64/ was used. The Gitignore files include x64/, but not Win32/. The commit adds support for both Win32/ and x64/.
* Added Addressables.
Prevent automatically generated addressable files to end up in Git.
* Update .gitignore to exclude packed Addressables and Android auto-generated files.
After years of use I've come up with some improvements to the
`JENKINS_HOME.gitignore` example.
- Major performance improvement: On very large Jenkins installations that
have been running for more than one year, there tends to be many builds
(hundreds of thousands of builds). The `builds` directory of these
jobs contain millions of files which would cause Git to hang for
several minutes on simple commands like `git status` and longer for
committing changes. `strace` was used on Git to figure out the
performance impact and this proposed change includes the optimization.
I also added a clear comment explaining the line's purpose.
- There's an example for how to include Jenkins encryption keys, and
there's a disclaimer informing the user why they shouldn't but still
giving an example.
- Comments have been reworded and slightly reformatted to be a little
more clear.
Cython extension modules built with `gdb_debug=True` spit out debug symbols in the `cython_debug` directory at the top level of the project. The files in this directory contain hardcoded paths and are not shareable/meaningful across environments, so I think it makes sense to include them in a default Python .gitignore.
Since October 2019, Raku is the name of the language formerly known as
Perl 6. This reflects the change. It's the same language, so changes
are mostly cosmetic.
In Umbraco v8 we have a new packages folder located under Umbraco/views/packages/...
This gets ignored by the current version. Adding this new line prevents this and includes all files and subfolders under this new location.
