I've seen similar questions but some are very old and some are not quite what I'm looking for or have no answers.
I have projects in Eclipse under /workspace/project1 and /workspace/project2. They are Gradle projects and are dependent on each other. I also have /workspace/project3 which is a Gradle project but independent.
I need to "upload" them to a git repo on Bitbucket. I installed EGit to help me with this. It asks me where my local repo is located and I don't know what to tell it. Should I create a repo per workspace or per group of dependent projects or what?
For example when I right click a project and press Team > Share > Git I get to this dialog and I don't know what I should fill in there.
Each (non-bare) git repository has a work directory in which the files of the currently checked out commit (referred to as HEAD) are stored.
By default, the work directory is the parent of the git metadata directory (named .git), but it can be detached through a config setting. For example: git config core.worktree /path/to/workdir
EGit cannot deal with repositories that have a detached work directory as answered here: EGit working directory not under the local repository
But irrespective of this limitation, you cannot split the work directory of a git repository among several workspaces.
Therefore, you should move the projects to the work directory to resemble this structure:
~/git/my-repo/.git
~/git/my-repo/project1
~/git/my-repo/project2
~/git/my-repo/project3
If project3 is independent of the others, it may remain where it is or be located somewhere else entirely.
A word of caution when planning to have interdependent projects spread across several git repositories. This makes the git repositories effectively interdependent as well, but without git having a dependency management tool.
To have EGit move the projects, you would enter project1 in the Path within repository input field.
Commonly used build files like the master pom.xml or corresponding Gradle files would be located in the root of the work directory. This also eases configuration of popular build services like Travis, Codeship and friends.
A few things to understand/keep in mind:
An Eclipse workspace is a logical container of projects, not necessarily a physical container. The folder in which a worksapce is located can also be a physical container of projects, meaning the project's files can be located in a folder under the workspace folder (this is the default location if you create a new project in Eclipse). But that is not a requirement; a project that is contained within a workspace can have its contents (its files) located in any location on your file system.
In most dev setups, the local git repos are located in a "standard" location in the user's home directory, namely %USER_HOME%/git/name-of-repo. Again, that's not a hard requirement, users have the option to clone or create repos in any location they choose.
So Eclipse eGit is showing you those 2 axes of flexibility. It's asking where you want to create your local git repo, which usually is different than your workspace folder. Use the Create... button to create it. I think at that point it will auto-populate the Path within repository field. If it does not, you can name that path anything you want (usually its the same as the project name, though not necessarily)
At the end of it all you'll have your workspace (logical container) as well as a local git repo which will be the physical location of the project contents.
Related
I am working on a project which has GitLab repository and the local repository is on a network folder so I wanted to create an Eclipse Workspace on that folder as one can share the project with the other team members but when I tried to build the project I got an error message which says that eclipse workspace can't be a UNC path, so my question is, is there any work-around way I can do this, for example is there any way I can let the OS (Windows 10) link a local folder to the one on the network so that every member would do the same and work on his own local folder and it will be automatically edited in the network folder?
Thanks
No, this is not possible since everyone needs their own cloned Git repository to work with.
For instance, switching the branch or staging files are per repository and would therefore affect everyone. When you clone a Git repository without the bare option, there will be a so-called working tree which is the location where the currently checked-out files are and this folder is not copied but mapped into your workspace. Everyone would not have a copy of those files but working with the same files.
Besides the editing conflicts you would have, another disadvantage of having a Git repository on a network drive is that it would be slower. Therefore one would not want to have this even if it were possible to have Eclipse projects on a network drive.
But since in most cases a Git repository including the working tree takes less disk space than in SVN the working copy of the same, it should not be a problem if everyone has a locally cloned Git repository.
The working directory should be visible on a WebDAV server and none of the parent folders should contain the repository itself.
I want to separate totally the folder for .git and the working directory (on a different drive, clean from project files and others).
Using Eclipse EGIT, the repository creation allows set of working directory (Target Location) within a path within the repository.
No way found to set GIT_DIR or working_directory within Eclipse. Linking not an option (Windows)
The project .location contains the place within the repository (and that is a binary file anyway), so that should be configurable.
Is there any way to move the working directory to a totally different place?
Is there a configuration option I have missed?
After editing the files, do I really have to push all to the server, then commit to git?
To summarize what has been written in the comments, EGit does not support Git repositories whose work directory is at a different location than the .git directory. I.e. the core.worktree configuration setting is not taken into account.
See also this open enhancement request: https://bugs.eclipse.org/bugs/show_bug.cgi?id=433451
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?")
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.
Issue
After importing an Eclipse project from a cloned git repository, I make some changes and commit - and wtf? I get a ".git" folder added to the project, the whole shebang with the heads and refs and worst of all the whole object database gets added to the project, all files/folders having that little question-mark icon signaling that the files have not been added / are not yet tracked by git. This .git folder exists in the actual Working Directory (how does that even make sense?). You can imagine what an annoyance this causes when trying to use the "Synchronize" tool/view (which is supposed to make life easier for committing, you can see all the changes and changed files and diffs).
Question (tl;dr)
How to correctly import an Eclipse project from a cloned git repository? I don't want a .git folder showing up in "Team > Synchronize" when I commit, let the .git folder reside somewhere else outside of my project.
Additional Info
I'm on Windows 7 using Eclipse Indigo and Egit.
I am using Egit to clone a git repo from http://git.apache.org/ (the ofbiz project, to be exact) and in the wizard I choose the option to import an existing project from this newly cloned repo.
Yes I am aware of how little I may expect from Egit. In fact, if there are any alternative ways (external git tool? command line git for windows? other?) to use a git-tracked project in Eclipse which keeps the actual .git stuff out of the project, i'd gladly abandon Egit.
When you clone a git repository, the default behavior is to create a .git folder inside the root of the local clone. You can change the default behavior by setting the GIT_DIR variable:
Git docs says:
"GIT_DIR
If the GIT_DIR environment variable is set then it specifies a path to use instead of the default .git for the base of the repository."
Depending on which terminal you use, you could set it using setenv or export.
For example in a bash terminal:
export GIT_DIR='[path_to_git_directory]'
After setting the variable, you should be able to clone and the .git directory should show up at the specified directory.
I totally agree - I can't imagine it would ever be anyones intent to commit the .git folder!
And git/EGit knows that this is the repository folder of the project, so it should be easy to implement the appropriate exception - so that this folder does not become part of the synchronization.
I know the following does not solve your problem, but in cases where you control the way files are layed out in the repository, you could choose to have the Eclipse project folder not be the root folder of the repository, but rather a sub-folder.
This also allows you to have stuff in the repository that should not show up in Eclipse, or even have multiple Eclipse projects grouped in one repository (if you should wish to do so).