Why is not recommended to have an Eclipse project folder as a Git repository?

Question

When sharing a project as git and trying to make the Eclipse project folder as the git repository, Eclipse says that it is not recommended to do so and that it should be outside the Eclipse workspace.

Why is that?

Solution 1

From Eclipse EGit help pages,

It is probably not a good idea to make a project the root folder of your Repository

The reason is that you will never be able to add another project to this Repository, as the .project file will occupy the root folder; you could still add projects as sub-folders, but this kind of project nesting is known to cause lots of problems all over the place. In order to add another project, you would have to move the project to a sub-folder in the Repository and add the second project as another sub-folder before you could commit this change.

Some more information

It is a good idea to keep your Repository outside of your Eclipse Workspace

There are several reasons for this:

The new Repository will consider the complete folder structure of the Eclipse workspace as (potential) content. This can result in performance issues, for example when calculating the changes before committing (which will scan the complete .metadata folder, for example); more often than not, the workspace will contain dead folders (e.g. deleted projects) which semantically are not relevant for EGit but can not be excluded easily.

The metadata (.git-) folder will be a child of the Eclipse Workspace. It is unclear whether this might cause unwanted folder traversals by Eclipse.

You can easily destroy your Repository by destroying your Eclipse Workspace

Solution 2

While I agree about keeping the repository outside the Eclipse workspace, and I would still make a git repo within an Eclipse project root directory (like in this answer).

Unless your program is composed of lots of little inter-dependent projects, I would limit one git repo to one Eclipse project.
A git repo is about recording the content of a tree structure, and if that tree represents one project, it is easier to manage, tag, branch, merge (as a coherent set of files).
If it represents multiple project, you are not sure anymore about what a tag like "1.0" represents for each of the projects in that Git repo.

Plus, I like to add the .project, .classpath and .settings to the Git repo (as "Does git exclude eclipse project files from a new repo by default?")

Comments

[KingCrunch]

never heard this statement. You should exclude (--> .gitignore) the eclipse metadata from git, but thats all.

[anton1980]

it looks like EGit developers don't actually use their own product... that's why

[ahmednabil88]

your .git repo location is good, but to make projects IDE independent its recommended NOT commit the .project, .classpath and .settings

[Vito De Tullio]

@YajliMaclo I never understood what is the problem sharing the ide-specific configuration files. All of the people in the project should use the same compiler version, and the same libraries. Different IDE normally don't share configurations, and, when they do, is with the same meaning.

[ahmednabil88]

@VitoDeTullio suppose your team having 2 types of developers, one of them use Eclipse and another use Netbeans, so sharing ide-specific configurations files not a good idea and may cause problems when importing the project from the repo

[Vito De Tullio]

@YajliMaclo I have worked on the same project with people using eclipse and intellij (and one guy with vim). We had no issues whatsoever; the only "issue" is that the setup of the project is split between two groups of people (we had a pair of days with some people using java7 and others already switched on java9)

[Line]

@VitoDeTullio and where is Java 8 in this story? ;)