a65b95938c
This commit adds a global ignore file for SlickEdit, a commercial editor.
SlickEdit will create the following files when the user sets up a workspace:
*.vpw Workspace file. Contains a list of project files associated with
the workspace.
*.vpj Project file. Contains the project’s settings, including the list
of source files.
*.vpwhist Workspace history file for Windows. Contains user session
information (list of open files, debugger breakpoints, etc.)
*.vpwhistu Workspace history file for UNIX/Linux/MacOSX. (Same as above.)
*.vtg Workspace tag file. Contains a database of source code symbols.
It is assumed that GitHub users will generally not want to store their
workspace and project files in a repository, so those files are ignored
globally. However, those files do not contain user-specific data so they
could be stored in a repository and shared among developers if desired for
a particular project. This can be done by adding rules like ’!*.vpw’ and
‘!*.vpj’ to the project’s .gitignore file.
The workspace history and tag files contain user-specific data, so they
should not be stored in a repository.
For more information, download the PDF user guide from:
http://www.slickedit.com/products/slickedit/product-documentation
Note: The user guide is 1400 pages long and over 13MB in size.
Searching for ‘vpwhist’ will lead to the section that discusses storing
these files in a repository.
A collection of .gitignore templates
This is GitHub’s collection of .gitignore file templates.
We use this list to populate the .gitignore template choosers available
in the GitHub.com interface when creating new repositories and files.
For more information about how .gitignore files work, and how to use them,
the following resources are a great place to start:
- The Ignoring Files chapter of the Pro Git book.
- The Ignoring Files article on the GitHub Help site.
- The gitignore(5) manual page.
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/ directory.
Contributing guidelines
We’d love you to help us improve this project. To help us keep this collection high quality, we request that contributions adhere to the following guidelines.
-
Provide a link to the application or project’s homepage. Unless it’s extremely popular, there’s a chance the maintainers don’t know about or use the language, framework, editor, app, or project your change applies to.
-
Provide links to documentation supporting the change you’re making. Current, canonical documentation mentioning the files being ignored is best. If documentation isn’t available to support your change, do the best you can to explain what the files being ignored are for.
-
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 who works with the applicable technology, rather than just you or your team.
-
Please consider the scope of your change. If your change specific to a certain language or framework, then make sure the change is made to the 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 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.
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 workflow
Here’s how we suggest you go about proposing a change to this project:
- Fork this project to your account.
- Create a branch for the change you intend to make.
- Make your changes to your fork.
- Send a pull request from your fork’s branch to our
masterbranch.
Using the web-based interface to make changes is fine too, and will help you by automatically forking the project and prompting to send a pull request too.
License
MIT.