If the .project and .classpath are already committed, then they need to be removed from the index (but not the disk)
git rm --cached .project
git rm --cached .classpath
Then the .gitignore would work (and that file can be added and shared through clones).
For instance, this gitignore.io/api/eclipse file will then work, which does include:
# Eclipse Core
.project
# JDT-specific (Eclipse Java Development Tools)
.classpath
Note that you could use a "Template Directory" when cloning (make sure your users have an environment variable $GIT_TEMPLATE_DIR set to a shared folder accessible by all).
That template folder can contain an info/exclude file, with ignore rules that you want enforced for all repos, including the new ones (git init) that any user would use.
As commented by Abdollah
Answer from VonC on Stack OverflowWhen you change the index, you need to commit the change and push it.
Then the file is removed from the repository. So the newbies cannot checkout the files.classpathand.projectfrom the repo.
If the .project and .classpath are already committed, then they need to be removed from the index (but not the disk)
git rm --cached .project
git rm --cached .classpath
Then the .gitignore would work (and that file can be added and shared through clones).
For instance, this gitignore.io/api/eclipse file will then work, which does include:
# Eclipse Core
.project
# JDT-specific (Eclipse Java Development Tools)
.classpath
Note that you could use a "Template Directory" when cloning (make sure your users have an environment variable $GIT_TEMPLATE_DIR set to a shared folder accessible by all).
That template folder can contain an info/exclude file, with ignore rules that you want enforced for all repos, including the new ones (git init) that any user would use.
As commented by Abdollah
When you change the index, you need to commit the change and push it.
Then the file is removed from the repository. So the newbies cannot checkout the files.classpathand.projectfrom the repo.
The git solution for such scenarios is setting SKIP-WORKTREE BIT. Run only the following command:
git update-index --skip-worktree .classpath .gitignore
It is used when you want git to ignore changes of files that are already managed by git and exist on the index. This is a common use case for config files.
Running git rm --cached doesn't work for the scenario mentioned in the question. If I simplify the question, it says:
How to have
.classpathand.projecton the repo while each one can change it locally and git ignores this change?
As I commented under the accepted answer, the drawback of git rm --cached is that it causes a change in the index, so you need to commit the change and then push it to the remote repository. As a result, .classpath and .project won't be available on the repo while the PO wants them to be there so anyone that clones the repo for the first time, they can use it.
What is SKIP-WORKTREE BIT?
Based on git documentaion:
Skip-worktree bit can be defined in one (long) sentence: When reading an entry, if it is marked as skip-worktree, then Git pretends its working directory version is up to date and read the index version instead. Although this bit looks similar to assume-unchanged bit, its goal is different from assume-unchanged bit’s. Skip-worktree also takes precedence over assume-unchanged bit when both are set.
More details is available here.
.project, .classpath currently not ignored
java - Why do people gitignore .classpath and .project? - Stack Overflow
Add .classpath to .gitignore
Any way to get rid of .project .classpath .settings/ files?
Alright. So in one of my repos we accidentally commited a file (.classpath). Now that file has different content depending on the jre developer is using and some other things.
Long story short, it shouldnt be in the repository.
The problem is now: how to remove it and add it to .gitignore. I cant just add it to gitignore because it's already comitted. Googling has brought me to this conclusion:
-
git rm --cached .classpath
-
add ".classpath" to .gitignore file
-
stage + commit + push
The problem is that this keeps the .classpath file locally, but it deletes it in the repository! So if I now pull the repo, it will delete my .classpath file. Instead of just leaving it alone and ignoring it.
Where am I going wrong?
These Eclipse-specific files make it easier to set up Eclipse and Visual Studio Code for a Java project.
In general, IDE and tool specific files (Eclipse, Jenkinsfile, GitHub workflows settings, etc.) should be shared as long as they are used and maintained. Otherwise, delete them.
Of course, if you use a different IDE than Eclipse and Visual Studio Code and do not use the Eclipse compiler in IntelliJ IDEA, these Eclipse-specific files are useless, but they do no harm. As long as you do not use functions like file or folder links (stored in the .project file), sharing these files does not lead to IDE lock-in.
In Maven and Gradle projects the .classpath file can be derived from the pom.xml or build.gradle file, but settings that cannot be derived like compiler settings (warnings and errors), formatter or save actions settings (which are stored in the project's .settings folder) should be shared so that everyone uses the same.
This also applies to the .project file, as it contains which natures the project has and which tooling is required. If something is missing, a dialog will ask if the missing plug-ins should be installed.
Eclipse puts these files into the project folder and not into the .metadata folder, because they are intended to be shared. But why there are people who do not share these files? Probably because of historical reasons. 15 or 20 years ago, there wasn't Git, Maven and Jenkins. In these days, a Java application was usually built on a developer's computer by manually exporting JARs or at best via some batch/shell scripts. This meant, making the same build on a different computer or even just with a different IDE or IDE version might led to a different result, causing a lot of trouble. IDE agnostic builds was the solution for this problem. Maybe that's why people today still think that everything have to be IDE agnostic and recommend to use Maven or Gradle. But these files are not shared to build a product to be shipped. Hopefully.
They're Eclipse specific, so they don't really belong to the project's source code. Developers might be using different IDEs, so Eclipse's .classpath would be useless for someone using IntelliJ IDEA for example.
Since the project most likely uses Maven / Gradle / some other build system, the IDE is capable of generating the classpath based on the pom.xml or build.gradle files, as you noticed. Only if there isn't a build system, and the project is IDE specific, it would be necessary to include those files to make sure the project keeps its meta-data. But that's an unlikely scenario in modern times and real life work situations.
It doesn't usually cause problems to include those (unless there are conflicting project specific configurations from different developers), but they're not necessary either. I don't include them since there's no advantage, and it keeps the root of the project cleaner.
I found out that the paths in my .gitignore file had a space in the end of each row. When I removed the space char from each line in .gitignore it worked fine. This is how I created my .gitignore file:
https://superuser.com/a/498909/27037
echo .classpath> .gitignore
echo .gradle/*>> .gitignore
and before I used this commands (does not work):
echo .classpath > .gitignore
echo .gradle/* >> .gitignore
This works for me:
.classpath
.gradle/
Make sure you git add . to stage the .gitignore file.