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`.
