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.
