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?
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
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?")
Related
If I try to put repository inside project folder
it warns it is not recommended to put git repository inside workspace.
If I try to create intermediate folder
it swears "overlaps the location of another project" at the stage of creating new project.
And if I try to create project inside workspace and repository outside, it moves the project also outside of workspace
So, the only way to use Git under Eclipse it totally abandon workspace?
If you choose the last solution you present, to deal with git and Eclipse, you will not abandon workspace, all your code will remain into your Project Workspace but you will get an additionnal folder somewhere else containing your same code, versioned, a local git repository. By choosing this solution, you can only version some parts of your project and you also avoid some possible conflicts that can arise when versioning your workspace project folder. You can also have a cleaner view of your code if you want it without eclipse metadata and do some complex git tasks on the commandline in this separate folder.
I'm developing a Symfony applicatoin and I'm trying to set up a Git workflow on Eclipse. The workspace (where the project files lies) are located on /home/sfprojects/testing/ and the Git repository is located on /var/git/testing.
Reading over and over all the Git resources I've could found (including "Pro Git" by Scott Chacón, and the EGit user guide (http://wiki.eclipse.org/EGit/User_Guide, among others), it's easy to understand why the Git repository and the Eclipse workspace should not share the same directory, now my big confusion is that I can not see a method to keep both things separated from each other.
Once I've created the Git repository through the wizard, all the project files are moved automatically from the Eclipse workspace to the working directory on /var/git/testing/testing/. For my big surprise, the new created Git repository became into the new project workplace on Eclipse with .git directory in the parent directory. It is not a obvious contradiction?. If I let the mouse pointer over the option "Use or create repository in parent folder of project" a very clear help tag with the following text:
When checked, this wizard will try to find or create a repository in the parent folder hierarchy of the selected projects.
Typically, newly created projects are located in the Eclipse workspace, thus repositories created this way would also end up in the Eclipse workspace.
This is not recommended for several reasons explained in the EGit user guide.
So, after some research, my logical conclusion is to create a Git bare repository and then link it to the project located in the workspace... wrong! bare repositories are not available to a Eclipse project.
I need a serious explanation on this.
Seems that I went wrong about what I thought was a contradiction in the EGit User Guide and the EGit behaviour about moving the project directory to the Git repository.
When the project files are moved as a working directory of the Git repository (with a Git metadata folder at the same level), they're still under the Eclipse control, as Eclipse workspace. But as EGit User Guide says (http://wiki.eclipse.org/EGit/User_Guide#Eclipse_Workspace_and_Repository_working_directory), the .git metadata folder should NOT be into the workspace... well that's when I was wrong, cause it is a Eclipse project/Git working folder... but it IS NOT an Eclipse workspace by any means, so the Git metadata folder is not editable, as any other source project file, just for Git (and the EGit Eclipse plugin, of course).
Yesterday and today i converted my eclipse juno project to multi module maven project in eclipse. I have 1 maven project of type 'pom-root' and all my other projects are modules. The modules have the root project as parent. This works correctly.
A few hours ago i did try to add the root project to egit, by simply right clicking the root project and picking share project -> egit.
I first created a new repository in a new directory, the result was that all my module project became empty and all source files were copied to the repository directory. Gladly i did see that and could recover easily by copying the files back.
Next after the failed attempt i tried to create the repository in the parent folder of project. This failed somehow and the root project became corrupt. After a lot of fiddling around i deleted the corrupt root project and created a new one of type 'pom-root', and somehow i managed to get everything running again.
Next i surfed to stackoverflow ( :-) ) and ask my question:
How can i put my multi module maven project in a new local git repository? (without losing or corrupting everything)
Summary: Delete your Eclipse projects (just their metadata, NOT their contents), then re-create them by importing them from the local repo.
Caveat: I'm at the "a little knowledge is a dangerous thing" stage, so treat this with suspicion.
I just went through this, and I think I have a solution/workaround.
The problem, I believe, is that most of Eclipse still doesn't grok projects nested inside other projects. When you shared your root project, EGit moved all of your project's files out of the Eclipse workspace into the local git repo and then updated Eclipse's metadata for the root project to reflect the new location of the files (good), but (since it is clueless about nested projects) that means it treated all the files in your child modules as though they were part of your root project and hence moved them into the git repo (that's OK) but didn't update the Eclipse project metadata for those child modules (that's bad). So Eclipse shows that you now have a bunch of (child) projects that don't have any files (not even a .project file, nor pom.xml). But if you ignore Eclipse and look directly in the working directory of the git repo, they're all sitting there happily (i.e. EGit copied the directory structure and all the files, including the child modules) and from git's perspective they are all currently untracked.
The solution (I believe) is: delete your Eclipse projects. No, really. But very carefully; see below. [Just to be safe, maybe use e.g. zip to take a backup copy of your lovely files that are sitting in the working directory of the repo. If they were already staged or committed this would be moot, but presumably at this point they aren't].
When you select each Eclipse project and right-click Delete, make sure that the "Delete project contents on disk (cannot be undone)" checkbox is NOT checked -- in other words, you are deleting the Eclipse metadata for each project (I did this for all the child modules and even for the root project) but you aren't deleting the files that are sitting in the working directory of the repo.
(I was worried that m2e might be too "helpful" and, as I deleted each child module, it might remove it from the parent's pom.xml, but thankfully that didn't seem to happen).
In the Eclipse Preferences for Team - Git - Projects, I do have "Auto share projects located in a git repository" enabled. That makes life easier but I assume that you could use less automagic approaches if you preferred.
Once all the relevant Eclipse projects have been deleted, use the Git Repositories view to Import Maven Projects; this creates new Eclipse projects (for the root project and for the child modules) with valid metadata that points to the files in the repo. Hallelujah.
I believe this works because one part of Eclipse that isn't clueless about nested projects is the import-maven-projects logic in m2e.
At this point all the files are still untracked, so next you probably want to select the root project and right-click Team --> Add to Index (which will also add all the child modules, I assume because it's oblivious to the nested projects and just treats them as extra files in the root project).
I wondered what would happen if I then added a new child module -- would it "just work" (and be shared in the git repo) or would it require more gyrations? I was pleased to find that (as far as I can see) it "just works": the Eclipse project metadata shows the files in the right place (in the git repo, as a child under the root project) and marks the project as shared in git.
So my guess is that if you or I had a time machine, the easy way to do this would have been to create the root Maven project, share that to EGit, and only then start creating the child Maven modules.
My environment (though it probably doesn't matter):
Eclipse 4.3.1 (Kepler SR1) with the usual versions of its components: m2e 1.4.0, EGit 3.0.3, m2e EGit connector 0.14.0.
I am migrating from Eclipse/SVN to Eclipse/Git and I am unsure what the best directory layout would be. I have looked at the Vogel/a guide, the Eclipse Wiki as well as the following threads: Is it better to keep Git repository inside or outside of Eclipse workspace? Should I store git repository in Home or Eclipse Workspace?
I am used to setting up eclipse like so:
~/projectA/workspace/.metadata
~/projectA/workspace/subproj1/.project
~/projectA/workspace/subproj2/.project
~/projectA/subproj1/.svn
~/projectA/subproj1/file1
~/projectA/subproj2/.svn
~/projectA/subproj2/file2
So the project holds all project related files i need. The workspace folder holds relatively little data like the local revision info, project descriptions and specific eclipse settings.
The subproj folder(s) hold all the source code but also the subversion meta info.
The subprojects are more (or less..) related but they all contribute to projectA.
The eclipse working directory is ~/projectA/subproj1, ~/projectA/subproj2, etc.
I am not completely sure if i could use a more or less similar layout with Git. Biggest difference would be the 'repo' dir.
~/projectA/workspace/.metadata
~/projectA/workspace/subproj1/.project
~/projectA/workspace/subproj2/.project
~/projectA/subproj1/.git
~/projectA/subproj1/file1
~/projectA/subproj2/.git
~/projectA/subproj1/file2
~/projectA/repo/subproj1
~/projectA/repo/subproj2
If i set it up like the following, do I still comply with the best practices as mentioned in the Wiki?
#eugener I would assume the following layout complies with the Egit manual?:
~/projectA/workspace/.metadata
~/projectA/workspace/subproj1/.project
~/projectA/workspace/subproj2/.project
~/projectA/subproj1/.git
~/projectA/subproj1/file1
~/projectA/subproj2/.git
~/projectA/subproj1/file2
I would suggest to comply with EGit Wiki simply because the the way Git works.
The main point of Git is fast branching and merging, which is accomplished in repository's workspace, location of which is fixed in the folder where your repo is. Actual repository is located one level down in .git folder.
When project in Eclipse is "shared" with Git all the files are automatically moved from Eclipse workspace where the project was created to the location of the git repo it was shared with. So project in Eclipse is just a shortcut. Branch switching replaces the files in Git workspace which is automatically reflected in Eclipse.
Im very new to git ingeneral, egit and github.
The problem:
Lets say I have a project for eclipse in c:/username/workspace name "Test". So I versioned it and pushed it up to github.
Now I can see all my Files in github under the directory "Test" in github. In example /src. The "Test" directory is not versioned. only the name of the repository is "Test".
My next step was to delete my local files and fetch my project again(For testing). After that I had to import my project again (but I had to use the new project wizard) over the egit view. Unluckily also the wrong scala version was detected. (Was a play framework project). So I had a big exclamation mark on the project view.
My questions:
What is the best practice to oush a project to github so everyone can participate? Everything under the project folder? Obviously some information got lost through the process.
How can I prevent to generate a new project every time someone clones the repository?
What about best practices for using git inside the workspace. Eclipse warned not to put the project inside the workspace.
Im coming from a subversion background :/. Maybe a general missunderstanding.
Thanks in advance
Switching from SVN to Git in an Eclipse environment can take some getting use to. (I'm still getting accustomed to it myself.) Keep in mind the difference between the role of the .git folder and the .svn folders for Git and SVN respectively. There is a .svn folder at every folder level in the working copy. There is no .svn folder in the traditional Eclipse workspace root. The "source controlled things" are subdirectories of the workspace, not the workspace itself. This is generally good because the workspace contains desktop specific settings that one generally doesn't want shared (much of it in the .metadata directory).
With Git, there is only one .git folder that contains everything. The first impulse is to do a
git init
at the workspace level. This would make the subfolders (the Eclipse projects) eligible for source control. But wait, so is .metadata. Of course you can ignore it. But you may have to ignore lots of other folders (projects) that you do not want source controlled. Of course, the .gitignore should be included. But others will have different files to ignore.
It turns out that its easier to use Git with Eclipse if you place the .git folder and its sibling source controlled folders (Eclipse projects) someplace else besides the workspace root. Your view in Eclipse doesn't change. You still see all your projects, both the Git-controlled and the SVN controlled and ones not shared at all. But underneath in the filesystem, the Git-controlled folders will be somewhere else. This is what EGit prefers.
On my desktop, I have a workspaces directory for most of my Eclipse workspaces. Now that I use EGit, I also have an egit directory where I keep the local EGit repositories. The Eclipse workspaces that share using EGit reference a subdirectory of egit. It's from these local Git repositories that one pushes and pulls from GitHub.
Sorry for the length. I got a bit carried away.