For template rules (modern style) in Qt project file,
this file is autogenerated by qmake.
Example old style (pro file):
SOURCES += src/1.cpp \
src/2.cpp
Example new style, uses template rules (pro file):
SOURCES += src/*.cpp
qmake auto generate files with list of objects
object_script.*.Debug
object_script.*.Release
This file is autogenerated by qmake. It imports static plugin classes for
static plugins specified using QTPLUGIN and QT_PLUGIN_CLASS.<plugin> variables.
This file is autogenerated for static build
The presentation software pdfpc [1] (which is handy for latex beamer slides) supports additional notes on the secondary screen provided by *.pdfpc files.
These can be autogenerated from latex documents with the pdfpcnotes package [2], thus should be ignored in a latex project (but not in others where they could have been created manually).
[1] https://pdfpc.github.io/
[2] https://github.com/cebe/pdfpc-latex-notes
[mkdocs](http://www.mkdocs.org/) is rising as an alternative to Sphinx for project's documentation. The default build command puts the generated documentation in a `site` directory at the root of the project which should be ignored.
From the Eclipse Documentation: "Make sure that the .project and .classpath files are under version control. These files must be stored in the repository so that other users checking out the projects for the first time will get the correct type of project and will get the correct Java build path." - http://wiki.eclipse.org/FAQ_How_do_I_set_up_a_Java_project_to_share_in_a_repository%3F
**Reasons for making this change:**
The file `replstate.xml` contains the history of the Clojure REPL
that Cursive adds to IntelliJ. Obviously that's user-specific,
and not relevant to other users.
**Links to documentation supporting these rule changes:**
This file is not well-documented, but in cursive-ide/cursive#1325,
the Cursive developers state that this is the REPL history file,
and that deleting it is acceptable troubleshooting if it's
causing trouble.
Our typical workflow has JS and related build outputs in the `build` directory.
Most users are on new SDKs, so we don't have to worry about these ignores.
Most users don't generate docs locally. If they do, it's easy to add the entry to their .gitignore later.
