Ignore timing.properties from takari-smart-builder
This extension is an alternative scheduler to build multi-module Maven projects.
It stores and updates timing for every build run in .mvn/timing.properties.
riosc [Wed, 11 Mar 2015 18:53:11 +0000 (15:53 -0300)]
removing aditional white space
removing this aditional white space avoid a mistake for beginners developers ignore the pod directory, because is confusing to note when they remove the '#' character and git still is tracking the pod dir.
jake johns [Tue, 10 Mar 2015 07:49:24 +0000 (02:49 -0500)]
Add ".env" to Laravel.gitignore
Laravel 5 uses vlucas/phpdotenv for env configuration.
http://laravel.com/docs/5.0/configuration#environment-configuration
Previous version used env.php files. the new configuration files do not have
.php extension
(cdep)illabout [Tue, 24 Feb 2015 07:10:30 +0000 (16:10 +0900)]
Remove cabal.config from Haskell.
The Stackage project provides a cabal.config which locks in a specific
package set. This file should be shared between developers project so
that everyone is developing using the same versions of packages.
William West [Wed, 11 Feb 2015 14:29:22 +0000 (09:29 -0500)]
Expand list of root-of-volume dotfiles
In addition to `.Spotlight-V100` and `.Trashes`, the following dotfiles
may appear at the root of all OSX volumes (not just external disks):
- `.DocumentRevisions-V100`: auto-save and versions storage
- `.fseventsd`: file system event storage
- `.Temporaryitems`: temp directory used by some applications instead of
/tmp and /var/tmp
- `.VolumeIcon.icns`: storage of custom icon for volume, if set
Karen Etheridge [Mon, 2 Feb 2015 01:10:53 +0000 (17:10 -0800)]
ignore new scratch directory for metadata
This directory is created by ExtUtils::MakeMaker starting with version
7.05_05, via this commit:
https://github.com/Perl-Toolchain-Gang/ExtUtils-MakeMaker/commit/b6a9eba5b0501dbe2fa0568a15dc588b1a289128
It was added to the default MANIFEST.SKIP in ExtUtils-Manifest 1.70, here:
https://github.com/Perl-Toolchain-Gang/ExtUtils-Manifest/commit/e0f44577f84521ded664a41b46021eae95a1a1af
andres-mancera [Thu, 22 Jan 2015 04:45:09 +0000 (20:45 -0800)]
Moving SynopsysVCS.gitignore into Global/.
Whether to use VCS or any other simulator is a choice of the individual designer rather than of the project as a whole.
andres-mancera [Wed, 21 Jan 2015 18:00:29 +0000 (10:00 -0800)]
Removing the last two lines since they are editor-specific (Namely, VI and Emacs).
As Carl has pointed out, they are covered by other templates under Global/.
Carl Suster [Thu, 15 Jan 2015 00:41:35 +0000 (11:41 +1100)]
Merge Pull Request #1338 for Eclipse
Fixes #1217.
Once again ignore .classpath and .project in the Eclipse template. This has
been requested in multiple PRs such as #1338 and #1221 and is essentially a
reversion of #805. I copy the explanation for this change from the discussion
in #1217 by @segfly:
*In short*:
I can't point to any counter-documentation off the top of my head. I just know
from experience these files pollute a project's repo without adding value
- that is, unless everyone contributing is using Eclipse and no-one is using
dependency management. And even then, the guidance provided by the eclipse docs
is bad advice.
*In Long*:
The .classpath file is used by Eclipse to maintain the project's classpath
during automatic compile (every save of a file). In the olden days, one would
manually configure the project within the Eclipse UI and include all the
dependent jars necessary to compile your project. Eclipse then wrote that
configuration out to the .classpath file.
In theory, this file could be shared with others so they did not have to
manually configure their eclipse classpath. In practice, I never saw it work
out quite so well due to eventual bloating of the classpath with needless jars
or jars that only existed on one person's machine. Mind you, many people back
then also used to check their dependent jars into version control along with
their source.
Dependency management tools like Gradle and Maven have done away with all that
of course. But they also integrate nicely with Eclipse and manage the project
classpath dynamically. The .classpath file is basically rebuilt based on
changes to the build.gradle file or pom.xml file. Effectively, this renders the
whole point of checking in the .classpath moot as it is easily rebuilt by the
Maven or Gradle plugin.
The .project file is another animal completely. It basically describes what
plugins should be applied to the project as configured in the Eclipse UI. Again
the theory is it could be shared and creates a happy world. But due to
different eclipse versions people may have, different plugins installed, etc.
sharing the .project file actually causes more issues. And I've seen many
projects unable to open due to a bad .project file - requiring one to delete it
anyway (which then of course, when someone recreates it, they inevitably check
it in over the old one and end up breaking someone else's environment).
The bottom line is, regardless of what the eclipse documentation says, these
are very much internal configuration files for eclipse and best left out of
a repo.
projects / gitignore.git / log