Refer to the biblatex manual at http://ctan.unsw.edu.au/macros/latex/contrib/biblatex/doc/biblatex.pdf:
(p.106): The name of the additional aux files is the base name of the main input file with the string -blx and a running number appended at the end.
[...]
Apart from these aux files, biblatex uses an additional bib file with the same suffix to pass certain control parameters to BibTeX.
[...]
When using Biber, biblatex writes a control file named example.bcf and ignores \blxauxsuffix.
Note: the running number mentioned in the documentation is not always added to the suffix.
From the man page for latexmk (http://manpages.ubuntu.com/manpages/raring/man1/latexmk.1L.html):
[...] the -recorder option with latex and pdflatex. In (most) modern versions of these programs, this results in a file of extension .fls containing a list of the files that these programs have read and written.
Latexmk specifies this option in its latex commands and so produces temporary files with this extension in latex projects.
Reverted a change that was causing build directories at the root folder to show up in git. If you need to ignore subdirectories the leading slash needs to be omitted.
If you open an REPL within your project with `lein repl`, your REPL history gets saved in .lein-repl-history. This file does not need to be committed to a repository
Store apps (or at least the Javascript ones) build to a "bld" directory.
Although "debug" and "release" are ignored, any custom build Configuration (created through configuration manager) will be added, unless we ignore the whole bld dir.
If you use package restore, you actually don't want this file
included. It's not needed. It's only needed if you version
packages. AKA, you only need this file if you are not ignoring
the "packages" folder.
I agree to ignore the NuGet packages folder, but I really think you should check in the repositories.config so NuGet PackageRestore can do it's magic when someone pulls the code and tries to build it...
Workspaces are real documents that can be opened, just like `xcodeproj`
documents. These documents are also generated/used by CocoaPods to
configure a project’s dependencies. For these reasons, there does not
seem a good reason to ignore these any longer.
