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.
- Ignore '*.moc' files (foo.moc created when foo.cpp contains a Q_OBJECT.)
- Ignore '/.qmake.cache' and '/.qmake.stash' as does the official Qt Creator project.
- add the `build/` directory to the .gitignore list (now created by pub).
- add the `.dart.precompiled.js` files (created by dart2js) to the ignore list.
And, sort and re-order the file.
These aren't really common patterns in the Node world, and if a Node project includes one of these types as files, they're as likely to want to include them in the project as not (`*.csv` is as likely to be a data source as `*.json`).
Submitting this for consideration.
The first thing that I do on every new project is to go in and uncomment the packages folder. With the prevalence of NuGet and prominence of its use in the Visual Studio environment, along with how well package restore *just works* now, I believe this should be the default.
While I understand that package restore isn't on by default, I would argue that the types of developers using NuGet _and_ a distributed SCM are the types of developers that would omit the binaries from source control.