.stack-work/ is a work directory used by the `stack` build tool.
The `stack` build tool has recently been gaining a lot of traction in
the Haskell community. It is very similar to the `cabal` build tool,
which also has entries in this Haskell .gitignore file.
Ignore files created by `\tikzexternalize`
When using TikZ & PGF with:
\usepackage{tikz} \usetikzlibrary{external} \tikzexternalize
It creates .dpth and .md5 files for the externalized tikzpictures.
See these pages in section 50 Externalization Library:
p.617 - 50.4.1 Support for Labels and References In External Files
p.621 - /tikz/external/up to date check
In the PGF manual:
http://mirrors.ctan.org/graphics/pgf/base/doc/pgfmanual.pdf
When using TikZ & PGF with:
`\usepackage{tikz} \usetikzlibrary{external} \tikzexternalize`
It creates .dpth and .md5 files for the externalized tikzpictures.
These files are automatically generated by Xcode and maintain
information regarding source control. Xcode is typically used
in Objective-C and Swift projects, so add these to the ignored files for
these platforms.
[Tex] Change *.mtc0 to *.mtc[0-9] *.mtc[1-9][0-9]
>`\@tocfile`
The name of the file containing the minitoc is constructed from `\jobname` and a suffix `\@tocfile`, which is `.mtc` (long extensions) or `.M` (short extensions) followed by the absolute number of the minitoc.
```
\if@mtc@longext@
\def\@tocfile{mtc\The@mtc}%
\else
\def\@tocfile{M\The@mtc}%
\fi
```
When using minitoc package, LateX often generates multiple .mtc files such as `*.mtc0`, `*.mtc1`, ..., `*.mtc13`, ... This patch allows one to ignore all *.mtc files from index 0 to index 99 (ignoring `*.mtc[1-9][0-9]`).
There are only two entries in this .gitignore, and both are not needed.
- .meteor/local is already ignored by the standard Meteor .gitignore that is included with every project. This is redundant and should b left solely to the standard Meteor .gitignore in case this changes in the future.
- .meteor/meteorite should no longer be in any Meteor project. Meteorite was a package manager for Meteor, but it has been replaced by an official package manager built into the Meteor CLI. This directory should not exist, except on out of date Meteor projects which already have this ignore present.
build/ already matches all directories named 'build' in the repository,
regardless of level. Gradle can have more than two levels of project nesting.
However, /*/build/ matches only the 'build' directories of 2nd-level projects.
Thus, the first pattern is more appropriate than the second.
Brendan Forster