8bc0e535bb
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.
A collection of .gitignore templates
This is GitHub’s collection of .gitignore file templates.
We use this list to populate the .gitignore template choosers available
in the GitHub.com interface when creating new repositories and files.
For more information about how .gitignore files work, and how to use them,
the following resources are a great place to start:
- The Ignoring Files chapter of the Pro Git book.
- The Ignoring Files article on the GitHub Help site.
- The gitignore(5) manual page.
Folder structure
The files in the root directory are for .gitignore templates that are
project specific, such as language or framework specific templates.
Global (operating system or editor specific) templates should go into the
Global/ directory.
Contributing guidelines
We’d love you to help us improve this project. To help us keep this collection high quality, we request that contributions adhere to the following guidelines.
-
Provide a link to the application or project’s homepage. Unless it’s extremely popular, there’s a chance the maintainers don’t know about or use the language, framework, editor, app, or project your change applies to.
-
Provide links to documentation supporting the change you’re making. Current, canonical documentation mentioning the files being ignored is best. If documentation isn’t available to support your change, do the best you can to explain what the files being ignored are for.
-
Explain why you’re making a change. Even if it seems self-evident, please take a sentence or two to tell us why your change or addition should happen. It’s especially helpful to articulate why this change applies to everyone who works with the applicable technology, rather than just you or your team.
-
Please consider the scope of your change. If your change specific to a certain language or framework, then make sure the change is made to the template for that language or framework, rather than to the template for an editor, tool, or operating system.
-
Please only modify one template per pull request. This helps keep pull requests and feedback focused on a specific project or technology.
In general, the more you can do to help us understand the change you’re making, the more likely we’ll be to accept your contribution quickly.
Please also understand that we can’t list every tool that ever existed. Our aim is to curate a collection of the most common and helpful templates, not to make sure we cover every project possible. If we choose not to include your language, tool, or project, it’s not because it’s not awesome.
Contributing workflow
Here’s how we suggest you go about proposing a change to this project:
- Fork this project to your account.
- Create a branch for the change you intend to make.
- Make your changes to your fork.
- Send a pull request from your fork’s branch to our
masterbranch.
Using the web-based interface to make changes is fine too, and will help you by automatically forking the project and prompting to send a pull request too.
License
MIT.