**Reasons for making this change:**
_Allowlisting with .gitignore is a technique for dealing with source trees that can have various different untracked local files such as generated output, packages installed through package managers, “working” files, config for individual developers, etc. Rather than trying to come up with some master list of all possible untracked files and add them to .gitignore, it can be easier to start by ignoring everything and then add specific directories back._
_I think the requirements for software development are changing and there is a need to offer an alternative to the denylist._
- https://jasonstitt.com/gitignore-whitelisting-patterns
- https://github.com/golang/go
Signed-off-by: kuritka <kuritka@gmail.com>
Conflicts with JetBrains.gitignore. Some files in this directory should be checked in.
Not sure about *.sln.iml, so I'm leaving that. The JetBrains.gitignore file contains commented-out IML stuff with instructions on when to uncomment.
With Go 1.18, support for Go workspaces will land.
Go workspaces are configured in `go.work`, which
contains paths to local development versions of
modules and therefore is not expected to be
commited.
See:
* https://github.com/golang/go/issues/45713
Three new files to ignore for GoHugo repositories:
- `/assets/jsconfig.json` - Quote from [JavaScript Building](https://gohugo.io/hugo-pipes/js/): "Hugo will, by default, generate a assets/jsconfig.json file that maps the imports. This is useful for navigation/intellisense help inside code editors, but if you don’t need/want it, you can turn it off."
- `hugo_stats.json` - Quote from [Post Build Resource Transformations ](https://gohugo.io/news/0.69.0-relnotes/): "The prime current use case for the above is CSS pruning in PostCSS. In simple cases you can use the templates as a base for the content filters, but that has its limitations and can be very hard to setup, especially in themed configurations. So we have added a new writeStats configuration that, when enabled, will write a file named hugo_stats.json to your project root with some aggregated data about the build, e.g. list of HTML entities published, to be used to do CSS pruning."
- `.hugo_build.lock` - Quote from [Fine Grained File Filters ](https://gohugo.io/news/0.89.0-relnotes/): "Hugo now writes an empty file named .hugo_build.lock to the root of the project when building (also when doing hugo new mypost.md and other commands that requires a build). We recommend you just leave this file alone. Put it in .gitignore or similar if you don’t want the file in your source repository."
If a user has ignored an asset (no matter how dubious that decision may be), they also want to ignore the .meta file. Instead of bringing back .metas that have been ignored, this template should trust that a user has ignored the files they want to ignore.
You'd encounter this issue if you had added an ignore for an asset and its meta above this Unity template, or if another template ignored an asset and meta.
In general excludes may be dangerous in these templates, as they can have unintended consequences on other templates.
>A note about backup files
One other notable change is that the backup file system has been removed. This was the system that would create kicad_sch-bak and kicad_pcb-bak files every time you save. The short story about why this is removed is that with recent changes to the way file saving works, it should no longer be possible for files to be corrupted if KiCad crashes during a save, and the generation of these backup files was seen by many users as annoying clutter. For more context about this decision, you can read the [thread on the developers mailing list](https://lists.launchpad.net/kicad-developers/msg44067.html).
>An new backup system that properly backs up the whole project (see the [GitLab issue](https://gitlab.com/kicad/code/kicad/-/issues/4763)) has been implemented to replace this feature. As always when using nightly builds, back up your files separately in case a KiCad bug breaks the built-in backup system.
https://forum.kicad.info/t/new-project-file-format/23705
This is a gitignore template for the AutoIt v3 Language. This tool automatically excludes files created by some of it's tools such as automated backups.
After spending a lot of time finding why my app won't run, just noticed that the gitignore I copied introduced a deletion/ignore rule of an internal folder used by the framework.
The current gitignore file deletes the folder `/system/Cache/*` and causes the following error when running the App from the CLI or the web server : `Class "CodeIgniter\Cache\CacheFactory" not found `; making the app unable to run.
I added the following rule to fix this : `!system/Cache/*`.
Note : this won't fix the bug if the system folder is renamed
Coq now uses .mlg rather than .ml4 (since https://github.com/coq/coq/pull/8763), so we have to ignore its generated dependency files. The `native_compute_profile_*.data` files are generated by `Set NativeCompute Profiling` (see https://github.com/coq/coq/pull/950). Finally `.coq-native` is a directory that may be generated in any subdirectory, not only at top level, so we should not use absolute paths for it.
The svg package creates two temporary files for each .svg file that is
included in the document (one .pdf file and one .pdf_tex file). These
are placed into a subfolder called svg-inkscape/ by default.
I added this .gitignore to a project that included a file named CoverageSearchModel.cs, and the file was wrongly ignored. This change fixes the incorrect use of the range operator on the Coverlet rules.
The problem here was two fold:
1. the folder "/target/" would be top-level of the repo only, it should be "target/" to properly exclude target folders anywhere in the repo
2. the default Rust/Cargo folder when compiling code is "debug/", which gets used perhaps more often that "target/", added that
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.
* Ignore files inside `.vscode-test`
[vscode-test](https://github.com/microsoft/vscode-test) is a testing framework for vscode extensions. Inside the `vscode-test` folder are stored one or more versions of vscode, which are used for testing a vscode extension.
* Update Node.gitignore
Since IntelliJ 2019.3 this file appeared in our git changes. It seems these are just cached information about remote repositories that are defined in Maven/Gradle.
In our IntelliJ projects where we are using Gradle, the file .idea/compiler.xml and files inside the .idea/artifacts folder are automatically generated by IntelliJ based on the Gradle build model. As these files are generated, they should be ignored in version control.
TeXnicCenter produces a status file named *.tps which holds information on currently open *.tex files and window positions. This most likely should not be checked in.
Having `release/` in an Android project gitignore means those apps which have different
build types files for `debug` and `release` will fall into this
and all `release` related files will be never added or will be removed from
repository at some point.
There are a number of OpenSSL-related file extensions (e.g., .pem, .crt,
etc..) that contain data that are generally best not committed to
repositories. This file contains several common file extensions that
often correlate to these types of files.
* Update Autotools.gitignore
Add ignore-rule for Makefiles generated by configure
(directly by config.status)
* Add some descriptive comment.
Add more descriptive comment to explain why Makefile should be ignore.
If you have the [Ionide](http://ionide.io/) tools installed you will get an `.ionide` directory created in each directory that you open with VS Code, regardless of whether or not you are using F#.
The xy package generates *.xyd files whenever the commands
\MakeOutlines
\OnlyOutlines
\ShowOutlines
\NoOutlines
are present in the LaTeX source. These automatically-generated files
contain the dimensions of figures typeset with xy and are recreated as
needed. This is documented on pp. 15f. of the XY-pic Reference Manual
(1999/02/16).
As automatically-generated, temporary files, they should be ignored.
from vim's documentation on `:mksession` (:help :mksession):
...
10. If a file exists with the same name as the Session file, but ending
in "x.vim" (for eXtra), executes that as well. You can use *x.vim
files to specify additional settings and actions associated with a
given Session, such as creating menu items in the GUI version.
we already have Session.vim ignored. the Sessionx.vim file, like
Session.vim, is a user file. a user would generally want that file kept
private or for themselves, and the public or a team fetching from or
sharing the repository generally have no interest in a file relevant
only to a particular user. so it's a good idea to get git to help us
avoid mistakenly sharing the file.
When IntelliJ project is created as a file-based (i.e. without `.idea` folder, but with `.iws`, `.iml` and `.ipr` files), and this is a Gradle or Maven project with auto-import, should ignore them as well for the same reason we ignore `.idea` folder content in that case.
When a Unity project is opened in Jetbrains Rider, it installs a editor plugin into the Assets/Plugins/Editor/Jetbrains folder to manage Unity->Rider integration. This plugins life cycle is managed by your local Rider install and is automatically updated by Rider. It should not be committed to source control. This is documented by Jetbrains here https://www.jetbrains.com/help/rider/Unity.html
This change should ignore both the Jetbrains plugin folder and its .meta file correctly. For completeness, it would be nice to also ignore the /.idea*/ settings folder that Rider autogenerates, but i see a PR implementing that change has already been rejected.
.ist files are makeindex style files, which determine how a
makeindex-generated index will look like. Therefore, they must be
included in source control.
* gitignore for JENKINS_HOME Jenkins settings
This allows an admin to use git to keep a backup of Jenkins settings
without tracking binary artifacts. Useful for preserving settings during
plugin upgrades.
Note: secret.key is purposefully not tracked by git. This should be
backed up separately because configs may contain secrets which were
encrypted using the secret.key.
See also:
* http://jenkins-ci.org/
* https://wiki.jenkins-ci.org/display/JENKINS/Administering+Jenkins
* Add a few entries to Jenkins gitignore
* Added leading slashes to ignored directories so that valid subdirectories aren't ignored incorrectly
* Added comment to recommend .gitignore placement; added leading slash for AssetStoreTools rule
* Added a leading slash to never ignore .meta files in the root Asset folder
ASP.NET Core projects no longer use Bower by default (since Bower is now deprecated), and instead create static files in the wwwroot/lib path. This path is can also be used by convention for ASP.NET Core developers, and since it's no longer populated by Bower, it is unituitive to be excluded by default.
This change removes the lines added by #2307.
**Reasons for making this change:**
VS default flow is now broken by excluding files required to run an ASP.NET Core project.
**Links to documentation supporting these rule changes:**
The changes to the ASP.NET Core templates was tracked by https://github.com/aspnet/templating/issues/48.
* Add more standard ignored files for Julia
In particular, this adds documentation build artifacts generated by Documenter.jl as well as Manifest.toml, which can appear in docs/, in test/, or at the top level.
* Clarify the intent of each ignored item
Also add a few more build artifacts from BinaryProvider/BinDeps.
Lerna is an increasingly popular tool within node ecosystem to manage package dependencies and having writes to a `lerna-debug.log` following the yarn and npm precedence when error is encoutered.
Rider has its own ignore file, so does Visual Studio. The ignore statements for Rider (idea) IDE should be removed from Visual Studio .gitignore file template.
* Add ignore rules for Pipenv
Pipenv uses Pipfile.lock to maintain Python package information
(metadata, hash, etc.) installed as described in Pipfile. Thus,
Pipfile.lock may vary on different operating systems, platforms
when collaborating. This PR adds Pipfile.lock into the Python
default gitignore. See http://pipenv.org
* Update Python.gitignore
Not to ignore Pipfile.lock in default, but explain
when and why it should be ignored in case of
collaboration. (adjusted according to comment
in github/gitignore#2977 by @drothmaler )
* Apply suggestions from code review
Co-Authored-By: JarryShaw <jarryshaw@icloud.com>
* Update Python.gitignore
As suggested by @shiftkey , elaborate on the problems that users might see with `Pipfile.lock`.
PEP-517 has resulted in some updates to the Python
build process. As a result, a new directory called
pip-wheel-metadata is created on fresh builds.
This PR adds this directory into the Python default
gitignore. See
e5f4bbb7dd/src/pip/_internal/req/req_install.py (L568)
QtCreator above 4.8 version is utilizing a so called "compilation database" which placed in the compile_commands.json and contains generated information.
Only people building Unity plugins will need to import the asset store tools plugin into their project, and it's a toss up whether they want to commit the tooling into their repo (they might or they might not want to, it highly depends on their workflow). The default .gitignore shouldn't be making this choice for these users.
Unity projects targeting the 2.0/3.5 runtime or built with mono < v5.0 generate `mdb` files, not `pdb` files.
Looks like the `crashlytics-build.properties` gets around in more than just the `StreamingAssets` folder, looking at [examples around the internets](https://github.com/auth0/sharelock-android/blob/master/app/src/main/assets/crashlytics-build.properties), so it should probably just be ignored as a filename.
Netbeans Linux and Windows Makefile-*.mk and Package-*.bash files in nbproject directories are automatically generated during compile. These files are continually updated, which can cause a long list of unnecessary files to add, commit, and push (or that are Untracked). This has been experienced for Linux and Windows C++ projects. Helpful supporting link: https://stackoverflow.com/questions/27490608/netbeans-c-and-git
Pyre is a new type-checker for Python developed by facebook in May 2018.
https://pyre-check.org/
It makes .pyre directory for storing result or cache for type checking.
This directory is environment dependent. So it should be ignored from Git.
Currently, CodeRush provides the capability to store team settings and images used in Rich Comments and they should be shared among all team members. I have corrected the gitignore file to exclude only personal settings.
In Laravel, we often use `artisan vendor:publish` to copy views, notifications etc from dependencies so that they can be customized. These views are created in <type>/vendor/<dependency> directory.
When using the current gitignore for Laravel, vendor is inserted like vendor/ which ignores all the directories named vendor anywhere in the source tree, including the customized views.
The proposed file change tries to fix this problem by ensuring only the root vendor directory is ignored by git.
We shouldn't ignore -cache.lib files, because it causes missing components in your schema
http://kicad-pcb.org/help/file-formats/ specifically mentions this:
> `-cache.lib`: … a local copy of all the symbols used in the corresponding schematic, so that when the folder containing a KiCad project is copied to a different PC, the schematic can still be opened and printed and will still look the same as the original draughtsperson intended - even if that other PC does not have those symbols in its main libraries (or has symbols that coincidentally have the same name but are completely different).
If checked the option "Always create backup copy" under Settings -> Save within Microsoft Word 2016 on macOS, when editing a docx file, a folder named as same as docx file name(without ext) will be created and placed a docx backup file named "Backup of DOCX_ORIGINAL_FILENAME.docx".
Add extra commented section to use when using Gradle or Maven auto-import.
These are mentioned in the original reference for optional excludes (https://intellij-support.jetbrains.com/hc/en-us/articles/206544839).
If this would be better as a separate, non-commented ignore file, let me know and I will resubmit.
**Reasons for making this change:**
PuTTYgen is a widely used alternative to OpenSSH under Windows.
This rule allows private keys ignoring.
If this is a new template:
- **Link to application or project’s homepage**: https://www.chiark.greenend.org.uk/~sgtatham/putty/
http://www.perl6.org
Just a start. Perl 6 creates these directories to
store pre-compiled versions of modules.
Perl 6 doesn't have a gitignore template yet, and it
doesn't use the same build and installation system as
Perl (5).
The PSoC is a popular microcontroller and the PSoC Creator is a great IDE that deserves a .gitignore so it's easier for people to share the _neccessary_ files for collaboration.
>not affiliated
Cadence Virtuoso is a commercial EDA tool used for custom IC (ASIC) design. This gitignore file
blacklists database lock files, the contents of run directories for layout versus schematic and
design rule checks as well as log files for a selection of tools inside the package.
2015-11-02 18:49:06 +01:00
152 changed files with 2909 additions and 447 deletions
@@ -18,10 +18,46 @@ the following resources are a great place to start:
## Folder structure
The files in the root directory are for `.gitignore` templates that are
project specific, such as language or framework specific templates.
Global (operating system or editor specific) templates should go into the
[`Global/`](./Global) directory.
We support a collection of templates, organized in this way:
- The root folder contains templates in common use, to help people get started
with popular programming languages and technologies. These define a meaningful
set of rules to help get started, and ensure you are not committing
unimportant files into your repository.
- [`Global`](./Global) contains templates for various editors, tools and
operating systems that can be used in different situations. It is recommended
that you either [add these to your global template](https://docs.github.com/en/get-started/getting-started-with-git/ignoring-files#configuring-ignored-files-for-all-repositories-on-your-computer)
or merge these rules into your project-specific templates if you want to use
them permanently.
- [`community`](./community) contains specialized templates for other popular
languages, tools and project, which don't currently belong in the mainstream
templates. These should be added to your project-specific templates when you
decide to adopt the framework or tool.
## What makes a good template?
A template should contain a set of rules to help Git repositories work with a
specific programming language, framework, tool or environment.
If it's not possible to curate a small set of useful rules for this situation,
then the template is not a good fit for this collection.
If a template is mostly a list of files installed by a particular version of
some software (e.g. a PHP framework), it could live under the `community`
directory. See [versioned templates](#versioned-templates) for more details.
If you have a small set of rules, or want to support a technology that is not
widely in use, and still believe this will be helpful to others, please read the
section about [specialized templates](#specialized-templates) for more details.
Include details when opening pull request if the template is important and visible. We
may not accept it immediately, but we can promote it to the root at a later date
based on interest.
Please also understand that we can’t list every tool that ever existed.
Our aim is to curate a collection of the _most common and helpful_ templates,
not to make sure we cover every project possible. If we choose not to
include your language, tool, or project, it’s not because it’s not awesome.
## Contributing guidelines
@@ -39,7 +75,7 @@ high quality, we request that contributions adhere to the following guidelines.
- **Explain why you’re making a change**. Even if it seems self-evident, please
take a sentence or two to tell us why your change or addition should happen.
It’s especially helpful to articulate why this change applies to *everyone*
It’s especially helpful to articulate why this change applies to _everyone_
who works with the applicable technology, rather than just you or your team.
- **Please consider the scope of your change**. If your change is specific to a
@@ -47,21 +83,56 @@ high quality, we request that contributions adhere to the following guidelines.
template for that language or framework, rather than to the template for an
editor, tool, or operating system.
- **Please only modify *one template* per pull request**. This helps keep pull
- **Please only modify _one template_ per pull request**. This helps keep pull
requests and feedback focused on a specific project or technology.
In general, the more you can do to help us understand the change you’re making,
the more likely we’ll be to accept your contribution quickly.
If a template is mostly a list of files installed by a particular version of
some software (e.g. a PHP framework) then it's brittle and probably no more
helpful than a simple `ls`. If it's not possible to curate a small set of
useful rules, then the template might not be a good fit for this collection.
## Versioned templates
Please also understand that we can’t list every tool that ever existed.
Our aim is to curate a collection of the *most common and helpful* templates,
not to make sure we cover every project possible. If we choose not to
include your language, tool, or project, it’s not because it’s not awesome.
Some templates can change greatly between versions, and if you wish to contribute
to this repository we need to follow this specific flow:
- the template at the root should be the current supported version
- the template at the root should not have a version in the filename (i.e.
"evergreen")
- previous versions of templates should live under `community/`
- previous versions of the template should embed the version in the filename,
for readability
This helps ensure users get the latest version (because they'll use whatever is
at the root) but helps maintainers support older versions still in the wild.
## Specialized templates
If you have a template that you would like to contribute, but it isn't quite
mainstream, please consider adding this to the `community` directory under a
folder that best suits where it belongs.
The rules in your specialized template should be specific to the framework or
tool, and any additional templates should be mentioned in a comment in the
header of the template.
For example, this template might live at `community/DotNet/InforCRM.gitignore`:
```
# gitignore template for InforCRM (formerly SalesLogix)
# Don't include the tmc-file rule if either of the following is true:
# 1. You've got TwinCAT C++ projects, as the information in the TMC-file is created manually for the C++ projects (in that case, only (manually) ignore the tmc-files for the PLC projects)
# 2. You've created a standalone PLC-project and added events to it, as these are stored in the TMC-file.
# Coverlet is a free, cross platform Code Coverage Tool
coverage*.json
coverage*.xml
coverage*.info
# Visual Studio code coverage results
*.coverage
*.coveragexml
@@ -178,6 +194,8 @@ PublishScripts/
# NuGet Packages
*.nupkg
# NuGet Symbol Packages
*.snupkg
# The packages folder can be ignored because of Package Restore
**/[Pp]ackages/*
# except build/, which is used as an MSBuild target.
@@ -202,12 +220,14 @@ BundleArtifacts/
Package.StoreAssociation.xml
_pkginfo.txt
*.appx
*.appxbundle
*.appxupload
# Visual Studio cache files
# files ending in .cache can be ignored
*.[Cc]ache
# but keep track of directories ending in .cache
!*.[Cc]ache/
!?*.[Cc]ache/
# Others
ClientBin/
@@ -251,6 +271,9 @@ ServiceFabricBackup/
*.bim.layout
*.bim_*.settings
*.rptproj.rsuser
*- [Bb]ackup.rdl
*- [Bb]ackup ([0-9]).rdl
*- [Bb]ackup ([0-9][0-9]).rdl
# Microsoft Fakes
FakesAssemblies/
@@ -271,6 +294,17 @@ node_modules/
# Visual Studio 6 auto-generated workspace file (contains which files were open etc.)
*.vbw
# Visual Studio 6 auto-generated project file (contains which files were open etc.)
*.vbp
# Visual Studio 6 workspace and project file (working project files containing files to include in project)
*.dsw
*.dsp
# Visual Studio 6 technical files
*.ncb
*.aps
# Visual Studio LightSwitch build output
**/*.HTMLClient/GeneratedArtifacts
**/*.DesktopClient/GeneratedArtifacts
@@ -286,8 +320,8 @@ paket-files/
# FAKE - F# Make
.fake/
# CodeRush
.cr/
# CodeRush personal settings
.cr/personal
# Python Tools for Visual Studio (PTVS)
__pycache__/
@@ -323,3 +357,42 @@ ASALocalRun/
# MFractors (Xamarin productivity tool) working folder
.mfractor/
# Local History for Visual Studio
.localhistory/
# Visual Studio History (VSHistory) files
.vshistory/
# BeatPulse healthcheck temp database
healthchecksdb
# Backup folder for Package Reference Convert tool in Visual Studio 2017
MigrationBackup/
# Ionide (cross platform F# VS Code tools) working folder
.ionide/
# Fody - auto-generated XML schema
FodyWeavers.xsd
# VS Code files for those working on multiple tools
.vscode/*
!.vscode/settings.json
!.vscode/tasks.json
!.vscode/launch.json
!.vscode/extensions.json
*.code-workspace
# Local History for Visual Studio Code
.history/
# Windows Installer files from build outputs
*.cab
*.msi
*.msix
*.msm
*.msp
# JetBrains Rider
*.sln.iml
Some files were not shown because too many files have changed in this diff
Show More
Reference in New Issue
Block a user
Blocking a user prevents them from interacting with repositories, such as opening or commenting on pull requests or issues. Learn more about blocking a user.
